This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
reverse debugging implementation
- From: David McQuillan <dmcq at fano dot co dot uk>
- To: gdb at sourceware dot org
- Date: Sun, 22 Aug 2010 14:39:14 +0100
- Subject: reverse debugging implementation
Hi,
I see gdb now supports reverse debugging. This is something I
implemented for myself a number of years ago with my own simulators when
I was working on testing some compilers and other stuff. That all died a
long time ago but some of the ideas from it might be useful if you
haven't done them already.
Firstly as far as I can see gdb saves all the state change for every
instruction. This is unnecessary, all you have to do is save the state
of the cpu every few thousand instructions and for each instruction only
save the state of memory locations before they are changed. Going back
one instruction then involves rolling back the memory changes, the
registers are set up then go forward n-1 instruction to go back one.
I also had debug instructions to mark the current spot, then one could
go between a few different different states easily to check on the
difference.
I think practically everything else I had about what to do about library
calls is there - I intercepted system calls so they weren't redone just
the old results returned so I had to save both before and after looks.
Special work had to be done about allocating and freeing space and I
only had serial files and no special device access so you can see I had
a fairly straightforward environment.
If you used virtual memory tricks it might be possible to save the state
of the memory that way instead of even taking before looks. It would
slow going backwards a bit but I never noticed any particular delay
going back an instruction and machines have sped up and there's lots
more memory nowadays.
Cheers,
David McQuillan