Re: Remote Debugging with NEXT Command

[Ken Mandelberg <km at mathcs dot emory dot edu>]

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.