This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Remote breakpoint problem
- From: Mark Salter <msalter at redhat dot com>
- To: hoogerbrugge at hotmail dot com
- Cc: gdb at sources dot redhat dot com
- Date: Fri, 14 Feb 2003 11:36:21 -0500 (EST)
- Subject: Re: Remote breakpoint problem
- References: <F11600s5DrTRIFuEG1j0001db87@hotmail.com>
>>>>> 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