Remote breakpoint problem

Remote breakpoint problem

[Jan Hoogerbrugge]

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)
- gdb sends a continue command immediatly

So a breakpoint is detected and communicated to gdb but gdb lets the 
application continue immediately without giving control to the gdb user. 
Does anyone know what is wrong?

I have used breakpoint_from_pc function to supply the breakpoint code.

Thanks,
Jan





_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

Re: Remote breakpoint problem

[Andrew Cagney]

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

> - gdb sends a continue command immediatly
> 
> So a breakpoint is detected and communicated to gdb but gdb lets the application continue immediately without giving control to the gdb user. Does anyone know what is wrong?
> 
> I have used breakpoint_from_pc function to supply the breakpoint code.

Re: Remote breakpoint problem

[Mark Salter]

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

--Mark

Re: Remote breakpoint problem

[Jan Hoogerbrugge]

>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

Re: Remote breakpoint problem

[Daniel Jacobowitz]

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

Re: Remote breakpoint problem

[Mark Salter]

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