Two steps forwards, one step back
The idea of reverse debugging seems to have been gaining ground recently.
Reverse debugging is where, as well as being able to step or run forwards
through your program in the traditional way, you can go in the other
direction. Like most forms of time travel, this would obviously be
phenomenally useful if were only possible.
One way to achieve this is to simply record all the details of the
execution run of a program, and then do your debugging on the resulting
data file (in which case as it's all post-mortem going backwards is
as easy as going forwards). This is the approach Robert O'Callahan
took with Chronicle, which is a plugin to valgrind. Chronicle's actually
been kicking around for over a year now without much development effort
as far as I can see -- it just suddenly appeared fully formed and then
sat there in that state.
Robert did
an Eclipse-based front end to Chronicle traces, and there's certainly
a lot to be said for the idea of dumping the traditional debugger UI in
favour of something more directly suited to analysis of execution traces.
But somehow I couldn't really get to grips with it (partly this is my
dislike of GUIs, I suspect).
The other piece of the puzzle is that the gdb folks have been
doing some work on reverse debugging too. The necessary UI, innards and
remote protocol support code all landed in the gdb CVS repository
relatively recently.
So in fact it's possible to get gdb to talk to chronicle traces
(including reverse debugging) just by writing a gdbserver which talks
gdb remote protocol on one end and talks to the chronicle query engine
on the other. The fact that Andrew
Sutherland has helpfully written
some Python bindings
and utility code for querying chronicle traces makes this easy, even.
Over the last few weekends I've been fiddling about with this idea,
and I've now got to a point
where it seems worth making available (in an 'alpha' kind of way):
pm215@canth:~/chronicle/chronicle-gdbserver$ chronicle-gdb tests/00_simple
/usr/lib/python2.5/site-packages/zope/__init__.py:19:
UserWarning: Module simplejson was already imported from
/var/lib/python-support/python2.5/simplejson/__init__.py, but
/var/lib/python-support/python2.5 is being added to sys.path
import pkg_resources
GNU gdb (GDB) 6.8.50.20081216
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
main () at tests/00_simple.c:2
2 int main(void) {
(gdb) s
main () at tests/00_simple.c:3
3 printf("Hello\n");
(gdb) s
4 printf("world\n");
(gdb) rs
3 printf("Hello\n");
(It does reverse continue and watchpoint and breakpoint too.)
For further waffle, tarball, installation instructions, etc, see
the web page.
Hopefully I'll be able to fix some of the things on the TODO
list and maybe try it out in anger. Longer term, perhaps I'll
throw it away in favour of some completely non-gdb based interface
to traces. I'm thinking perhaps something that let you easily plug
in code to identify 'events' specific to your program (eg "loaded
HTML page", to pick a browser example) so you didn't have to do all
your debugging at the very lowest level all the time. OTOH recent gdb lets you
embed a Python interpreter so perhaps you could move in that
direction without abandoning a familiar UI...
| 