This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
[reverse] A "toy" implementation of reverse execution
- From: Michael Snyder <msnyder at redhat dot com>
- To: gdb at sources dot redhat dot com
- Date: Fri, 03 Jun 2005 12:55:25 -0700
- Subject: [reverse] A "toy" implementation of reverse execution
Hey folks,
Here's a "toy" implementation of a target that can,
to a very limited extent, act as if it's offering
reverse execution to gdb. I hope it will be useful
for trying out ideas. It should be useful for both
the "bookmark" approach and the "reverse-stepi" method.
What I've done is, starting from the "sample" program in RDA,
I added the ability to understand "tfind" requests, and then
added on a module that could read simplified tracepoint frames
from a file, and then serve them back to gdb.
Then I generated a trace frame file from the testsuite program
"break.c", starting at main and saving a tracepoint for every
instruction. It only took about 157 frames. ;-)
Now, if I feed that file to my rda-derived trace frame server,
"tfind next" becomes equivalent to "stepi", and "tfind prev"
becomes equivalent to "reverse-stepi".
With those as primatives, reverse-step turns out to be,
to first approximation at least, fairly easy:
define reverse-si
tfind -
end
define si
tfind
end
define unstep
reverse-si
set $foo=$trace_line
while $foo==$trace_line
reverse-si
end
si
end
As several of us speculated, the algorhythm for stepping backward
involves first taking a backstep, then establishing the line range
and stepping out of it, and finally taking one forward step.
I've created a branch and checked in my modified rda, along with
a hacked-up gdb that I'm using to help create trace frame files.
The branch is "msnyder-tracepoint-checkpoint-branch", and y'all
are welcome to play with it. There's a README-CHECKPOINTS file.