Re: [discuss] Support for reverse-execution

[Paul Schlie <schlie@comcast.net>]

> From: Michael Snyder <msnyder@redhat.com>
>> Paul Schlie wrote:
>> Alternatively to attempting to specify an interface to a lone commercial
>> reversible simulator,
> 
> I don't think that's what we're doing -- these commands are meant
> to be generically useful, as soon as anyone else can support
> backwards execution.

- Sorry for the misinterpretation; but as noted, it seems generally more
  useful to simply add the capability to GDB, thereby little if any
  functionality need be dependant on the target simulator, and further by
  doing so may actually support both check-pointing and undo/reverse
  execution, on all existing targets, regardless of whether or not they are
  simulated, or physical targets.
 
>> or presume the intelligence need be "remote" to GDB;
> 
> We're not doing that either -- the user interface makes no
> assumption about the target interface.

- Then there seems no need to define a reverse-xxxx set of commands at the
  GDB/target-stub boundary (unless I misunderstand the purposed of the
  earlier threads of dialog)?

>> 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.
> 
> Well, that's an idea that some of us (me, at least...) have  thought about
> too -- but it's, if not orthogonal, at least separable from this discussion.
> If gdb asks the target to step backwards or continue backwards, we really
> don't care how the target accomplishes this

- Sounds like you are presuming the "intelligence" to be remote and distinct
  from GDB, which I believe is fundamentally a less than an ideal premise.

> (eg. whether by restoring a saved state, or actually reversing the execution
> of individual instructions).

- It should be clearly understood that it's factually impossible to define
  reciprocal semantics for all instructions; therefore the fundamental basis
  of any undo/reverse execution facility has to be based on the ability to
  capture state to revert the "effects" of the execution, not "execute"
  logically reciprocal instructions. (If this is not understood, then its
  likely premature to attempt to define any interface to support the
  capability.)

> I've thought all along that the "bookmark" idea is separable from the
> "run backwards" idea.

- There're essentially identical, with the exception that one captures
  and provides a vehicle to backup to a previously named/designated
  (bookmarked) state, the other enables the same but to typically to a
  previously relative state. (single-step reverse execution in it's most
  general implementation is nothing more than reversing to a previously
  sequentially captured instruction by instruction check point diff)

By recognizing this, there's no need to rely on any information beyond that
which GDB already has access to to implement (although may be improved by
by simulators which can capture memory state change diffs more efficiently
than by brute force)