Re: [discuss] Support for reverse-execution

Paul Schlie
2005-05-20T15:49:31Z

Alternatively to attempting to specify an interface to a lone commercial
reversible simulator, or presume the intelligence need be "remote" to GDB;
I wonder if it may be more sensible to consider initially defining the basic
generic facilities by which GDB may directly support undoable/reversible
execution, and checkpoint features.

More specifically, as ISA semantics do not generally have deterministic
reciprocal semantics, it's only possible to support reverse execution
by literally being able to either maintain a list of all state changes
associated with each instruction/command's execution and unwind them,
and then optionally proceed forward again.

Therefore it seems likely sufficient to initially begin by defining
support for the following core facilities:

Basic GDB support for check pointing and reverse execution:

- enable-checkpoints: initializes machine state and program memory to
all 0's upon prior to program startup/initialization. (see below)

- save-checkpoint [Optional-Name] => checkpoint [N [Optional-Name]],
saves a diff between the programs present state and it's previous
state, and marks the current undo-state diff (see below) as being
equivalent to this checkpoint.

- restore-checkpoint [N | Opional-Name]; sets machine and memory state
to the cumulative difference between all 0's and the designated
checkpoint diff. [this is insensitive to the target's stub supporting
state-diff, as GBD is responsible for storing and computing state-point
restores on behalf of the target]

- enable-undo/reverse: sets flag to request state-diff from target
stub upon (step, next, etc.) commands.

- (step, next, etc.): as normal, but requests the state-diff from the
target stub between successive command executions if reverse-execution
flag is enabled. (This may also be supported without target stub support
for state-diff, as GDB has direct access to both the target's machine
state, and memory state; although target stubs may likely be capable
of more efficient diff's if they are capable of tracking memory updates
more efficiently than simply looking after the fact.)

- undo/reverse: undoes/reverses the previously issued command, by
un-diff'ing the present machine and memory state with the previously
returned diff. (which is likely sufficient and substantially more time
and resource efficient than attempting to otherwise effectively
single-step record all intervening individual instruction execution
diff's, which could also be enabled if desired, although likely not
necessary in general.)

Basic Target stub facilities to improve reverse execution efficiently:

- state-diff: the target returns the diff between the target's present
state and it's previous state, which may be used if available in lieu
of GDB directly calculating machine and memory state diffs, but would
likely only be substantially more efficient if the target stub were
capable of more efficiently tracking and accumulating diffs by directly
monitoring memory state changes, rather than determining them after
the fact, as may be done likely efficiently by a target simulator and
then simply communicated by publishing the cumulative diffs as requested
by GDB; which seems nice and simple, and minimally invasive.)