Re: [Reverse debugging] A small demo / test program

[Michael Snyder <msnyder at specifix dot com>]

What is this?

Two things -- (1) A test for the new branch of gdb with the reverse
debug patch, and (2) A modest "proof of concept" for the idea of
making something more useful out of the "gdbreplay" concept.

So, gdbreplay is a companion of gdbserver, which allows you to make a
log of a remote debugging session and then "play it back" later.  Its
major limitation is that it will only play back the remote debugging
log in exactly the same sequence as the original debugging session.

I've written a fairly limited prototype program that can take
approximately the same log, and let you play it back more naturally,
as if it were actually a "live" executing target (within some limits
of course).

You can look at the log file (~msnyder/break/break4.trace), and 
immediately see that it does not closely resemble the original log of
the remote protocol traffic -- but that it contains a subset of the
same semantic information.  This log was generated mostly by hand, but
I'm working on a post-processor, and I ultimately don't see any
obstacle to using the original log generated by gdb as input to a
replayer.

Also, for historical reasons, my replayer was built out of 'rda', but
I see no technical obstacle to building one either from parts of
gdbserver or from scratch.

A more complete implementation of this could probably replay all of
the remote protocol messages from the log (including those for
threads, shared libraries etc.), and not just the registers and memory
messages as this one does.

--------------------------------------------------------------

For the purpose of testing and demonstrating reverse debug, 
this demo accepts commands from gdb including:
  'g', 'G', 'm', 'M' (register and memory state)
  's', 'c', 'bs', 'bc' (step, continue, reverse-step, reverse-continue)
  'Z0', 'z0' (software breakpoints)

Using those and the saved log, it does a fairly convincing
job of pretending to execute a program, both forward and 
in reverse.  The log contains snapshots of the machine stack
at every execution stop event, so it is always possible to 
get a backtrace and to look at local variables.


I am thinking about this as a possible way of adding 
reverse debugging test cases to the gdb test suite.

Michael

PS: for people who can't log into sourceware.org, 
next time I'm thinking about hosting on the gcc 
compile farm (http://gcc.gnu.org/wiki/CompileFarm),
but for now you can check everything out from cvs
and build it yourself:

Patched gdb: msnyder-reverse-20080609-branch 
Patched rda: msnyder-tracepoint-checkpoint-branch

For the test load (the 'break' program and log), see
this post:
http://sourceware.org/ml/gdb/2005-06/msg00027.html