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.