This is the mail archive of the gdb@sources.redhat.com 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


>>>>> Jan Hoogerbrugge writes:

>> From: Mark Salter <msalter@redhat.com>
>> To: ac131313@redhat.com
>> >>>>> 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.

But there is no breakpoint in place when gdb sends the step instruction.

>> >> - 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)

So, why did the stub report that it stopped at foo, rather than the
next instruction.

--Mark



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