From: "Abid, Hafiz" <Hafiz_Abid@mentor.com>
To: Ken Mandelberg <km@mathcs.emory.edu>,
"Paul_Koning@dell.com" <Paul_Koning@dell.com>
Cc: "gdb@sourceware.org" <gdb@sourceware.org>
Subject: RE: Remote Debugging with NEXT Command
Date: Wed, 11 Jun 2014 10:01:00 -0000 [thread overview]
Message-ID: <EB3B29AD43CA924DA27099BC85192376E0FAEA5C@EU-MBX-02.mgc.mentorg.com> (raw)
In-Reply-To: <539776CD.50104@mathcs.emory.edu>
> -----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
next prev parent reply other threads:[~2014-06-11 10:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-10 21:02 Ken Mandelberg
2014-06-10 21:13 ` Paul_Koning
2014-06-10 21:21 ` Ken Mandelberg
2014-06-11 10:01 ` Abid, Hafiz [this message]
2014-06-11 15:24 ` Ken Mandelberg
2014-06-11 10:26 ` Luis Machado
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=EB3B29AD43CA924DA27099BC85192376E0FAEA5C@EU-MBX-02.mgc.mentorg.com \
--to=hafiz_abid@mentor.com \
--cc=Paul_Koning@dell.com \
--cc=gdb@sourceware.org \
--cc=km@mathcs.emory.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox