Re: Remote breakpoint problem

["Jan Hoogerbrugge" <hoogerbrugge@hotmail.com>]

>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 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963