This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Remote breakpoint problem

From: Mark Salter <>
>>>>> Andrew Cagney writes:

>> Hi,
>> I am porting gdb to a new target processor were remote debugging is used. I have a problem with breakpoints. When I place a breakpoint on foo followed by a continue I see the following communication between gdb and the stub on the other side:
>> - the instruction at foo is saved
>> - foo is replaced by a breakpoint instruction
>> - gdb sends a continue command
>> - the stub reports the breakpoint hit (signal = 5, pc = foo)
>> - gdb replaces the code at foo with the saved instruction
>> - gdb sends a step instruction command
>> - tbe stub reports again a breakpoint hit at foo (signal = 5, pc = foo)

> Shouldn't this stop beyond foo?

I wonder if the stub is flushing the icache after gdb puts the
saved instruction back...
Caches are properly syncronisched. The respone of the remote target and its stub is correct as far as I can see. It is gdb that issues a continue command to the stub after hitting the breakpoint and single stepping the instruction on which teh breakpoint was placed.

This is what gccint.texinfo says:
Software breakpoints require @value{GDBN} to do somewhat more work.
The basic theory is that @value{GDBN} will replace a program
instruction with a trap, illegal divide, or some other instruction
that will cause an exception, and then when it's encountered,
@value{GDBN} will take the exception and stop the program.  When the
user says to continue, @value{GDBN} will restore the original
instruction, single-step, re-insert the trap, and continue on.

Protect your PC - get VirusScan Online

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]