Re: [discuss] Support for reverse-execution

[Paul Schlie <schlie@comcast.net>]

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.)