This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]