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

Eli Zaretskii
2008-10-16T18:27:02Z

> 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.