Re: [discuss] Support for reverse-execution

[Russell Shaw <rjshaw@netspace.net.au>]

Eli Zaretskii wrote:
>>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?

It'd be better to store the state of every step in to a circular buffer
of size 1000 (the user could change that size with a command). Then you
could just: "back 10"  to go to the point that would have been 10 steps
ago, or "back 3 myfunc" to go back to the third last call of myfunc().
That way, there's only one backwards command to remember, and maybe a
command to change the history buffer size.