Re: [discuss] Support for reverse-execution

[Paul Schlie <schlie at comcast dot net>]

> From: Michael Snyder <msnyder@redhat.com>
>>>> 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)?
> 
> <tag-dont-take-this-as-criticism>
> The user interface makes no *assumption* about the target
> interface, but that doesn't mean that the target doesn't
> *also* need an interface.  Both have been discussed in this
> thread, but they're not tied together.

- I'd just caution against defining user commands which are in general
  much more difficult and expensive to support; i.e. defining any
  command which may specify a state which has not been previously likely
  recorded, as then it implies that the state needs to be unwound to the
  closest known point preceding it and then forward executed to the new
  desired state (which the simulation may have never "stopped" at before)

  More specifically for example, one may step past a function call, where
  the state preceding and after the call is now known, but the state
  preceding the previous instruction reverse-step-i may not be supported
  by the simulator naturally, and may require that the simulation be undone
  (which is always easiest) to the point preceding the call and then forward
  executed until the desired preceding instruction state is reached, etc.

  (Therefore an "undo/reverse" command is most likely the best basis for
  basic reverse simulation support, as it restricts reverse execution to
  only those points which the simulator had previously terminated it's
  simulation at previously; and other commands may be best only defined
  after such features are more broadly supported by at least a few
  simulators, and/or by GDB directly. Just as a thought.)