This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [discuss] Support for reverse-execution
- From: Paul Schlie <schlie at comcast dot net>
- To: Michael Snyder <msnyder at redhat dot com>
- Cc: Daniel Jacobowitz <drow at false dot org>,Eli Zaretskii <eliz at gnu dot org>,<gdb at sources dot redhat dot com>
- Date: Fri, 20 May 2005 17:35:16 -0400
- Subject: Re: [discuss] Support for reverse-execution
> 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)