Re: Remote Debugging with NEXT Command

Ken Mandelberg <[email protected]>
Newsgroups gmane.comp.gdb.devel
Message-ID <[email protected]>
On 06/10/2014 05:12 PM, [email protected] wrote:
>
> On Jun 10, 2014, at 5:02 PM, Ken Mandelberg <[email protected]> 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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.