Return to Reverse Execution

[Michael Snyder]

Over the past several months, there's been some great discussion
of this topic, and even some trial patches sent out for comment.

I'd like to start preparing a real submission for approval.
I'm testing the waters now, to see how close we may be to
converging on an acceptable interface spec.

So here is my proposed gdb user interface.
   1) A set of new commands that mimic the existing ones,
   to include:
	reverse-step (rs)
	reverse-next (rn)
	reverse-continue (rc)
	reverse-finish (rf)

   2) A mode setting that will cause all execution commands
   to be performed in reverse:
	set exec-direction [forward backward]

That gives users the choice of backing up once, or continuously.

Here's my proposed target vector interface:

   target_ops.to_set_exec_direction (int);

This keeps the target vector simple -- no need for discreet
vectors for reverse-proceed, reverse-wait etc.  If the target
doesn't export this method, it cannot go backwards.

And here's my proposed remote protocol interface:

New requests:  "bs" (backward step), and "bc" (backward continue).
Unlike the forward versions, they will not carry an argument for
a signal number to be passed to the target -- can't think how we
would implement signals in reverse...

Comment?


Footnote: I'm making this an interface spec, specifically to avoid
tying it to any model of implementation.  My idea is that GDB (core)
does not know *how* the target implements reverse execution -- and
does not care.  It could be by using checkpoints, it could be that
most of the work is done on the gdb side, or that most of the work
is done on the remote side.  The interface makes this invisible.  It
may work one way for remote, a different way for a direct simulator
interface, and a completely different way for native linux or hpux.
The details will be hidden either in the target module or on the
other side of the target interface (eg. remote protocol).

Postscript: It would probably also be a good idea to make up
an interface spec for checkpoints  --  this proposal doesn't
address that, as I argue that it's orthogonal to reverse execution
(except from the implementation side).