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]

[Reverse debugging] A small demo / test program


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.




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