Remote Debugging with NEXT Command

Remote Debugging with NEXT Command

[Ken Mandelberg]

I'm doing remote gdb deugging to a stub implemented on the target over 
tcp. SI works and NEXT works well enough skipping over a function call.

What can be very slow is NEXT from one C statement to the next.

When NEXT skips over a function call it implements it by setting a 
breakpoint at the return address.

When NEXT skips from one C statement to the next, it does it by doing 
repeated SI's. This forces the target to send back a bunch of state at
each SI. This is slow and very slow if the C statement actually has a 
loop in it.

Is there any way around this other than carefully avoiding NEXT in the 
worst cases and manually setting breakpoints/CONT?

Re: Remote Debugging with NEXT Command

[Paul_Koning]

On Jun 10, 2014, at 5:02 PM, Ken Mandelberg <km@mathcs.emory.edu> wrote:

> I'm doing remote gdb deugging to a stub implemented on the target over tcp. SI works and NEXT works well enough skipping over a function call.
> 
> What can be very slow is NEXT from one C statement to the next.
> 
> When NEXT skips over a function call it implements it by setting a breakpoint at the return address.
> 
> When NEXT skips from one C statement to the next, it does it by doing repeated SI's. This forces the target to send back a bunch of state at
> each SI. This is slow and very slow if the C statement actually has a loop in it.
> 
> Is there any way around this other than carefully avoiding NEXT in the worst cases and manually setting breakpoints/CONT?

If your stub supports breakpoints, it will take less work for GDB to do the stepping.  Basic stepping involves placing break instructions and restoring the content, repeatedly.  That’s a lot more round trips but it requires less stub magic.

	paul

Re: Remote Debugging with NEXT Command

[Ken Mandelberg]

On 06/10/2014 05:12 PM, Paul_Koning@dell.com wrote:
>
> On Jun 10, 2014, at 5:02 PM, Ken Mandelberg <km@mathcs.emory.edu> wrote:
>
>> I'm doing remote gdb deugging to a stub implemented on the target over tcp. SI works and NEXT works well enough skipping over a function call.
>>
>> What can be very slow is NEXT from one C statement to the next.
>>
>> When NEXT skips over a function call it implements it by setting a breakpoint at the return address.
>>
>> When NEXT skips from one C statement to the next, it does it by doing repeated SI's. This forces the target to send back a bunch of state at
>> each SI. This is slow and very slow if the C statement actually has a loop in it.
>>
>> Is there any way around this other than carefully avoiding NEXT in the worst cases and manually setting breakpoints/CONT?
>
> If your stub supports breakpoints, it will take less work for GDB to do the stepping.  Basic stepping involves placing break instructions and restoring the content, repeatedly.  ThatÂ’s a lot more round trips but it requires less stub magic.
>
> 	paul
>
>

Yes, the stub supports breakpoints. Thats why NEXT through a function 
call works so well. gdb is smart enough to ask the stub to set a 
breakpoint at the return address,

When gdb is just trying to get to the next statement in the current 
function with NEXT, it sends the stub a bunch of SI's, which is the
problem since its so slow.

I can put more logic in the stub, but I can't change what gdb does, and 
gdb doesn't give the stub any indication that it is doing NEXT.

RE: Remote Debugging with NEXT Command

[Abid, Hafiz]

> -----Original Message-----
> From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On
> Behalf Of Ken Mandelberg
> Sent: 10 June 2014 22:21
> To: Paul_Koning@dell.com
> Cc: gdb@sourceware.org
> Subject: Re: Remote Debugging with NEXT Command
> 
> On 06/10/2014 05:12 PM, Paul_Koning@dell.com wrote:
> >
> > On Jun 10, 2014, at 5:02 PM, Ken Mandelberg <km@mathcs.emory.edu>
> wrote:
> >
> >> I'm doing remote gdb deugging to a stub implemented on the target over
> tcp. SI works and NEXT works well enough skipping over a function call.
> >>
> >> What can be very slow is NEXT from one C statement to the next.
> >>
> >> When NEXT skips over a function call it implements it by setting a
> breakpoint at the return address.
> >>
> >> When NEXT skips from one C statement to the next, it does it by doing
> >> repeated SI's. This forces the target to send back a bunch of state at each
> SI. This is slow and very slow if the C statement actually has a loop in it.
> >>
> >> Is there any way around this other than carefully avoiding NEXT in the
> worst cases and manually setting breakpoints/CONT?
> >
> > If your stub supports breakpoints, it will take less work for GDB to do the
> stepping.  Basic stepping involves placing break instructions and restoring
> the content, repeatedly.  That's a lot more round trips but it requires less
> stub magic.
> >
> > 	paul
> >
> >
> 
> Yes, the stub supports breakpoints. Thats why NEXT through a function call
> works so well. gdb is smart enough to ask the stub to set a breakpoint at the
> return address,
> 
> When gdb is just trying to get to the next statement in the current function
> with NEXT, it sends the stub a bunch of SI's, which is the problem since its so
> slow.
> 
> I can put more logic in the stub, but I can't change what gdb does, and gdb
> doesn't give the stub any indication that it is doing NEXT.
> 
Have you looked at the range stepping? It might be what you are looking for.
https://sourceware.org/gdb/onlinedocs/gdb/Continuing-and-Stepping.html#range-stepping

Regards,
Abid

Re: Remote Debugging with NEXT Command

[Luis Machado]

On 06/10/2014 10:21 PM, Ken Mandelberg wrote:
> On 06/10/2014 05:12 PM, Paul_Koning@dell.com wrote:
>>
>> On Jun 10, 2014, at 5:02 PM, Ken Mandelberg <km@mathcs.emory.edu> wrote:
>>
>>> I'm doing remote gdb deugging to a stub implemented on the target
>>> over tcp. SI works and NEXT works well enough skipping over a
>>> function call.
>>>
>>> What can be very slow is NEXT from one C statement to the next.
>>>
>>> When NEXT skips over a function call it implements it by setting a
>>> breakpoint at the return address.
>>>
>>> When NEXT skips from one C statement to the next, it does it by doing
>>> repeated SI's. This forces the target to send back a bunch of state at
>>> each SI. This is slow and very slow if the C statement actually has a
>>> loop in it.
>>>
>>> Is there any way around this other than carefully avoiding NEXT in
>>> the worst cases and manually setting breakpoints/CONT?
>>
>> If your stub supports breakpoints, it will take less work for GDB to
>> do the stepping.  Basic stepping involves placing break instructions
>> and restoring the content, repeatedly.  ThatÂ’s a lot more round trips
>> but it requires less stub magic.
>>
>>     paul
>>
>>
>
> Yes, the stub supports breakpoints. Thats why NEXT through a function
> call works so well. gdb is smart enough to ask the stub to set a
> breakpoint at the return address,
>
> When gdb is just trying to get to the next statement in the current
> function with NEXT, it sends the stub a bunch of SI's, which is the
> problem since its so slow.
>
> I can put more logic in the stub, but I can't change what gdb does, and
> gdb doesn't give the stub any indication that it is doing NEXT.

If the code only moved in a specific direction, this logic/optimization 
of just continuing to a specific next statement's associated address 
would work just fine.

In practice, though, code can jump around and go back, like branches, 
loops and optimized code.

Therefore GDB needs to do individual instruction-steps in order to sense 
line number changes. When it detects such a change, it will stop and let 
the user know.

The next line could be 200 lines above, or a single line below. It is 
hard to predict.

Skipping functions is easier though, you just continue to its return 
address and that's it.

It is an area that could probably be improved. Range-stepping is a step 
towards that goal.

Luis

Re: Remote Debugging with NEXT Command

[Ken Mandelberg]

Thanks all!

We had missed taking advantage of range stepping in the stub, and not 
used the vCont packet. It's made all the difference for NEXT.