[Reverse debugging] A small demo / test program

[Reverse debugging] A small demo / test program

[Michael Snyder]

Folks, this is a little demo that I've cooked up,
to test and illustrate the ideas of :
  * reverse debugging (step, continue, breakpoint), and
  * doing something with the gdbreplay concept.

This is mainly aimed at you other gdb maintainers for now,
and to make it as easy as possible, I've set everything up
to run from my home dir on sourceware.org.  If you can log in
to sourceware.org, you're golden.  If not you'll have to
check out and build stuff from cvs, and in the future I'm
looking at an alternative hosting site for demos.

In a follow-on msg I'll talk about what this is actually
doing: for now I'll just outline how to look at the demo.

You'll need two login shells on sourceware.org.  In the
first one, do this:

  cd ~msnyder/break
  ../builds/rda/samples/sample -t break4.trace <socket id>

The socket id will default to "2345", but if two of you
happen to try to run it at the same time, you'll collide.
You can use "1234" or something.


And now from the 2nd login shell:

  cd /home/msnyder/break
  ../builds/gdb/gdb/gdb break

You're now looking at a copy of testsuite/gdb.base/break.
Now do this:

(gdb) set trust-readonly
(gdb) break factorial
(gdb) break marker1
(gdb) break marker2
(gdb) break marker3
(gdb) break marker4
(gdb) target remote :2345 (or your chosen socket id)
(gdb) tfind start
(gdb) continue

You should hit the breakpoint at "factorial", and you will be
able to do a backtrace and evaluate local variables.

You should hit the breakpoint at "factorial", and you will be
able to do a backtrace and evaluate local variables.

Continue a few more times, as factorial recurses and the stack
grows deeper.  Backtrace should continue to work.  Eventually
factorial will return, and you will hit one or more of the
breakpoints at marker1, marker2, marker3, and marker4
(in sequence).

Now do this:

(gdb) reverse-continue


This should take you back to the previous breakpoint.
You can do this repeatedly, using backtrace to confirm
that you are indeed progressing backward through the
recursive function calls.

You can alternate between "continue" and "reverse-continue"
at your discretion.

At some point, preferably before you reach the beginning,
disable the breakpoints and try this:

(gdb) reverse-step

Having got the idea by now, you should be able to convince
yourself that reverse-step is doing what you would expect,
and that you can step backwards all the way to the entry
point of main if you so choose.

You can alternate between "step" and "reverse-step" at
will, and it should do what you would expect it to do.

If you run past the end of main, you can simply set
a breakpoint anywhere and "reverse-continue" to get
back to a known state.

If you somehow get hosed, you can use "tfind start"
to return to the start state.

If you have a chance to try this, I would appreciate hearing
about how it goes for you, if you run into any problems etc.

Thanks much,
Michael

PS: In case you're wondering, no child program is actually
being executed here.  It's all done with mirrors, a recorded
execution sequence being replayed from a log.  However, gdb
does not know this, and the gdb commands (and remote protocol
sequences) are real, exactly as they would be for a "real"
reverse-execution target such as SID.

More in follow-on message.

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

[Michael Snyder]

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