Re: Faster stepping amidst breakpoints

Pedro Alves
2011-02-01T15:12:10Z

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