Re: Remote breakpoint problem

Jan Hoogerbrugge
2003-02-14T16:28:45Z

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

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.

Cheers,
Jan

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online