This is the mail archive of the gdb@sources.redhat.com 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] 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.


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