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: Daniel Jacobowitz <drow at false dot org>,Dan Shearer <dan at shearer dot org>,<gdb at sources dot redhat dot com>
- Date: Sat, 21 May 2005 11:03:32 -0400
- Subject: Re: [discuss] Support for reverse-execution
> From: Daniel Jacobowitz <drow@false.org>
>> On Fri, May 20, 2005 at 09:52:45PM -0400, Daniel Jacobowitz wrote:
>> Frank has contributed that sid would more readily support the sort of
>> snapshot-based reconstruction that you're talking about (thanks Frank).
>> I think that allowing the target to provide infrun with a view in which
>> "single step backwards" is possible and then implementing that under
>> the covers in the target stack would still be the way to go - but I
>> don't think that's a legitimate objection to supporting a smart
>> simulator which does it internally.
>
> BTW, a thought to consider - again, one which will only be interesting
> when there's a system to which it applies.
>
> What most of these single-stepping commands want to do, in the absence
> of watchpoints, is see the PC sequence over a timeline, choose a
> stopping state, and go to that state. For some simulator it may be
> substantially more efficient to just ask the target for a history of PC
> values for some number of cycles, all at once, and then tell it which
> one of those we're interested in. That would work for reverse-next,
> for example.
- Tracing a subset of the states is one thing, tracing and recording all
states can be quite another; where like most things, the significance
of "some" vs. "all" is relative to the detail inherent in the model of
the system being simulated. In the simplest ISA simulation case without
attempting to model a complex HW world around the processor in detail,
it's not necessarily unreasonable to record all of the most recent N
cycle states, presuming N is large enough to be useful; although tracing
anything likely reduces simulation performance by at least a factor of 10
vs. tracing nothing between termination points, it's not likely a big deal
when a typical simulation interval may only otherwise require a fraction
of a second, but can easily become a big deal when the complexity of a
simulation may otherwise be measured in minutes (as the very nature of
interactive debugging implies some minimal latency so the pilot doesn't
feel compelled to take naps while attempting to interactively analyze
their system's behavior between supposedly interactive requests; as
otherwise things become counterproductive, as the pilot can easily
loose their train of thought).
> I don't know the level of computation involved in these snapshots in
> Simics; perhaps an intelligent simulator, when told to go backwards,
> would reconstruct a series of "frames" all at once and cache them, so
> this is a non-issue. For some other simulator not yet available,
> perhaps it's not.
- Not to be too redundant, but just to try to emphasis the one point
which I do feel is important; which is that it's likely important for
GBD to initially define a set of commands which are most likely easily
supported, as it's likely better to have broad multiple target support
for a simpler set of capabilities, than very limited target support for
a sophisticated set of capabilities in the absents of the former;
"undo/reverse" essentially represents this minimal baseline command
functionality, all others are substantially more complex to support in
the general case.