Re: Remote breakpoint problem

["Jan Hoogerbrugge" <hoogerbrugge at hotmail dot 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