Mirror of the gdb mailing list
 help / color / mirror / Atom feed
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



  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