Re: [discuss] Support for reverse-execution

["Eli Zaretskii" <eliz@gnu.org>]

> Cc: Dan Shearer <dan@shearer.org>, gdb@sources.redhat.com
> From: fche@redhat.com (Frank Ch. Eigler)
> Date: 20 May 2005 20:05:13 -0400
> 
> The point of the other simulation gentleman on this thread is that by
> using state snapshots as the basic target-side primitive, one can
> implement backward stepping on the gdb side in a way that will work
> even with non-brilliant targets.  (By the way, this does not require
> actual bulk transmission of the state snapshots to gdb, just some sort
> of management protocol.)

This leads me to another idea.  Perhaps we should implement a
checkpointing infrastructure in GDB, and allow the user (perhaps not
by default, but as part of some mode) to go back to every place where
the program stopped, for whatever reason: breakpoint, watchpoint,
single-stepping, etc.  That is, each time the inferior stops, ask the
target for the information that fully describes its state, store that
state description, and allow the user to rewind the target to any of
the stored states.

I think this would be a great feature to have in all kinds of targets,
including native, since the user can then step forward from the
checkpoint to reach any point in between.

Think how many times you've did a "next" over a function call, just to
find out that the bug is inside the function which you just
overstepped, or did a "continue" just to find out at the next
breakpoint that the problem you are tracing happened in between this
and the previous stop location.  An ability to rewind back to the
previous stop is something to kill for in such situations.

(Btw, I vaguely remember that Turbo Debugger of yore had something
like that.  Hmmm... I should try to dig out my old copy of that and
see if I'm right.)

If we implement something like that, perhaps we could ditch all the
reverse-* commands whose names we are discussing at such length in
this thread, and instead implement only one command, called, say,
"rewind" or "backup" or some such.  That, and a set/show mode command
to enable checkpointing would be enough, I think, to have 99% of the
functionality originally suggested in this thread.

How would this suggestion of mine map to the remote targets and
simulators that support checkpointing on the target side?