Re: [discuss] Support for reverse-execution

[Paul Schlie <schlie@comcast.net>]

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