public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Cc: Daniel Jacobowitz <dan@codesourcery.com>,
	Joel Brobecker <brobecker@adacore.com>,
	Maxim Grigoriev <maxim@tensilica.com>,
	Marc Gauthier <marc@tensilica.com>,
	Stan Shebs <stan@codesourcery.com>
Subject: Re: Faster stepping amidst breakpoints
Date: Tue, 01 Feb 2011 15:12:00 -0000	[thread overview]
Message-ID: <201102011512.24360.pedro@codesourcery.com> (raw)
In-Reply-To: <20110131151229.GA2915@caradoc.them.org>

On Tuesday 01 February 2011 15:12:35, Daniel Jacobowitz wrote:
> On Mon, Jan 31, 2011 at 08:49:51AM +0400, Joel Brobecker wrote:
> > > Consider "set breakpoint always-inserted".
> > > I've been wondering lately if we should flip the default.
> > 
> > I like the idea of changing the default.
> > 
> > Do you know what the risks would be?  I looked at the code, and
> > there isn't something obvious/delicate, it seems.  Perhaps we might
> > find ourselves forgetting to re-insert breakpoints, or inserting
> > them twice? I think you guys have more experience than we do?
> 
> As far as I can remember (you know how much GDB development I do
> nowadays), the only risks were if GDB crashed and left the application
> with breakpoints inserted.  Of course, I'm in favor of GDB not
> crashing.
> 
> Pedro, Stan, any thoughts?

Regarding the OP's:

>Certain GDB operations involve a lot of single-stepping,
>which can be really slow on certain targets (especially
>embedded targets) because of that latency."

and the $subject:

> Faster stepping amidst breakpoints

... scenario, I'm not certain always-inserted alone helps that
much, because what always-inserted mainly affects, is whether
GDB removes breakpoints before giving the prompt to the
user, after the whole command finishes; and whether a
"break" or "delete" command inserts/removes breakpoints
in the target immediately.  In all-stop mode, without
displaced stepping enabled, when stepping amidst
breakpoints, even with "breakpoint always-inserted on",
GDB _will still_ remove/insert all breakpoints to single-step
over a location that has a breakpoint.

It sounds to me that what you need to optimize that
use case, is to make GDB smarter into only
remove/inserting the breakpoint being stepped over,
instead of always remove/inserting _all_ breakpoints.

-- 
Pedro Alves

  parent reply	other threads:[~2011-02-01 15:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-22 15:06 Maxim Grigoriev
2011-01-24  8:04 ` Daniel Jacobowitz
2011-01-24 21:08   ` Maxim Grigoriev
2011-01-31  7:47   ` Joel Brobecker
2011-01-31 15:39     ` Daniel Jacobowitz
2011-02-01  3:23       ` Joel Brobecker
2011-02-01 18:44         ` Michael Snyder
2011-02-03  4:55           ` Joel Brobecker
2011-02-02 17:10         ` Daniel Jacobowitz
2011-02-03  4:46           ` Joel Brobecker
2011-02-13 15:17         ` Mark Kettenis
2011-02-14  3:27           ` Joel Brobecker
2011-02-14 10:50             ` Joel Brobecker
2011-02-01 15:12       ` Pedro Alves [this message]
2011-02-03 22:54     ` Maxim Grigoriev
2011-02-04 16:06       ` Tom Tromey
2011-02-04 19:32         ` Maxim Grigoriev
2011-02-04 16:33       ` Daniel Jacobowitz

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=201102011512.24360.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=brobecker@adacore.com \
    --cc=dan@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=marc@tensilica.com \
    --cc=maxim@tensilica.com \
    --cc=stan@codesourcery.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).