[RFA] Displaced stepping just enable in non-stop mode

Eli Zaretskii eliz@gnu.org
Thu Oct 16 18:27:00 GMT 2008


> Date: Thu, 16 Oct 2008 08:34:22 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Pedro Alves <pedro@codesourcery.com>, teawater@gmail.com,
> 	gdb-patches@sourceware.org, brobecker@adacore.com,
> 	msnyder@vmware.com
> 
> On Thu, Oct 16, 2008 at 10:12:37AM +0200, Eli Zaretskii wrote:
> >   . Why isn't it better to use displaced stepping, if supported, even
> >     if non-stop mode is not in effect?  I think the linkage between
> >     the two is confusing and unnecessary.
> 
> It is generally good to use displaced stepping.  But in some
> circumstances it is slower, and in others it doesn't work at all.  It
> requires we have a small scratchpad area on the target which is
> writeable and executable.  By default we use the area at _start; this
> doesn't work on some simulator targets, on targets which execute code
> from ROM or flash memory, or during reverse debugging.
> 
> Some of those cases could be fixed by adding a user knob for where to
> put the scratchpad, though others can't.
> 
> It's linked to non-stop because for non-stop it is required.

Sorry, I don't get the logic of this decision.

Can we reliably use displaced stepping, or can't we?  If we can do
that reliably in vast majority of use-cases, we should do that even
without non-stop.  If we cannot do that reliably enough, we shouldn't
turn it on even with non-stop mode, or maybe refuse to turn on
non-stop, rather than risk screwing the users.

Since we are prepared to decide that turning non-stop turns on
displaced stepping, I understand that in most cases displaced stepping
does work, which brings me to the conclusion that we could use
displaced stepping even without non-stop.

We could also try to detect if it works, and display a warning if we
think it won't (RE the cases you described above).

> I'm not sure what else to call displaced stepping.  "Step around
> breakpoints"?

The text mentions "out-of-line stepping", which sounds better to me.



More information about the Gdb-patches mailing list