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.