Re: [discuss] semantics, "replay debugging" vs. "reverse debugging"

["Frederic Riss" <frederic.riss@gmail.com>]

Hello,

2008/10/20 Michael Snyder <msnyder@vmware.com>:
> Just to make sure we're all on the same page,
> I'm gonna state what I believe is true, and invite
> discussion or contradiction.
>
> Replay debugging --> ability to record an execution
> sequence and "play it back" (repeat it) with some
> degree of determinism.
>
> Reverse debugging --> ability to make the inferior
> process "back up" to a previous state, eg. reverse
> step and reverse continue-to-breakpoint.
>
> They're related but not identical.  One could theoretically
> have one without the other, although in practice all
> presently existing reverse-debug targets (that I know of)
> are implemented by using record and replay.

For what it's worth, I spent some evenings a few weeks ago starting a
remote reversible gdbserver implementation as a valgrind skin. I've
the 'record' part nearly done, but I've stopped working on it due to
personal priorities inversion. My idea was that I'd use the recorded
history to reverse the execution, but that I'd let the virtual
processor do the replay itself (ie. simply let the target run form the
state I would have restored).

Of course, I was aware that some syscalls aren't 'reversible' and I
was wondering how to report that to the user. My first idea was to
just say: "You're using reverse debugging, watch your steps!". I see
that 'replaying' the history can be useful in such cases, and I could
certainly implement that on top of my history record.

However, now I'm wondering: can't the current implementations 'rewrite
the past'? My scheme of record->reverse->rerun was expected to allow
the user to modify thing in the past execution and then watch the
consequences. If it's possible for them, where is the decision made
when to switch between replay and rerun?

Take the above with a grain of salt, as I haven't worked on that
project for quite some time, and I haven't yet implemented the
reverse/rerun part.

Fred.

> One could have reverse without record/replay if,
> for instance, one had a machine architecture where
> all instructions were reversable, ie. the machine
> itself could reverse-execute an instruction.
>
> And an example of a record/replay implementation
> without reverse debugging capability would be
> Michael Chastain's (circa 1999) implementation
> of Linux system-call based record and replay, which
> could deterministically replay a recorded program
> execution, but did not have reverse-step or
> reverse-continue-to-breakpoint.
>