Re: [discuss] Support for reverse-execution

Paul Schlie
2005-05-20T23:32:55Z

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