This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Remote breakpoint problem
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Jan Hoogerbrugge <hoogerbrugge at hotmail dot com>
- Cc: msalter at redhat dot com, ac131313 at redhat dot com, gdb at sources dot redhat dot com
- Date: Fri, 14 Feb 2003 11:34:08 -0500
- Subject: Re: Remote breakpoint problem
- References: <F11600s5DrTRIFuEG1j0001db87@hotmail.com>
On Fri, Feb 14, 2003 at 05:28:43PM +0100, Jan Hoogerbrugge wrote:
> >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.
If you single-step over the instruction at foo, and the stub reports a
stop at foo, something is wrong. You're stopped at the _following_
instruction.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer