Re: [discuss] Support for reverse-execution

[Paul Schlie <schlie@comcast.net>]

> From: Daniel Jacobowitz <drow@false.org>
> On Fri, May 20, 2005 at 09:41:58PM -0400, Paul Schlie wrote:
>> - Supporting HW co-simulation is certainly interesting, but fundamentally
>>   no different; it only extends the definition of "state" typically by
>>   literally exposing some of the logical CPU/I/O/Peripheral/outside-world
>>   state in various levels of details depending on the goals of the model,
>>   and/or simulation itself. (but would guess likely beyond the near term
>>   goals of attempting to enable GDB support for basic reversible execution?)
> 
> Why should it be?  This is another reason that I consider the simulator
> a perfectly reasonable place to have the logic.

- The predominant downside of such a presumption, is that then NxM targets
  would need to add support to broadly enable the capability, rather than
  broadly enabling within GDB, while allowing a target to improve it.
  
> 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.

- Possibly the only reasonable way to do, as the ability to "single step
  backwards" to a state with the simulation environment may have never
  previously terminated at is substantially more difficult to support
  efficiently than simply reverting to a previously reached stable state.

> - but I don't think that's a legitimate objection to supporting a smart
> simulator which does it internally.

- I only object (or observe alternatives) to defining a set of commands
  which are presently apparently unique to a particular commercial tool's
  abilities, and which if presumed to form the basis of the requirements
  for reversible simulation could become an impediment for GDB to support
  simpler more easily implemented facilities. Conversely, if it were
  initially presumed that the initial basis for reversible simulation were
  based on the support of a recursive "undo/reverse" command, then it would
  be much easier for a broader number of targets (and even potentially GDB
  itself) to support.

> When someone implements reversible debugging in a free simulator and
> wants to integrate that with GDB, they'll have the choice of doing the
> remaining steps in their simulator or in GDB.

- Although our views may differ, I accept and support the simple reality
  that those to invest the time and resources in a development, have the
  greatest say in the decisions. (In this case if the desire is to define
  an interface for a single lone proprietary tool, likely in satisfaction or
  natural result of a commercial commercial contract to do so, then let it
  be; but attempting to justify it as a good thing is a bit of a stretch).

>>   [And suspect you'll find that most HW savvy simulation environments have
>>    very limited if any support for "reversible" simulation, beyond
>>    checkpoint-restart. As on a cycle by cycle basis, tracking and recording
>>    incremental state changes would typically cripple the simulation, and
>>    potentially even exhaust disk storage for complex models, but limited
>>    forms do exist, and are useful.]
> 
> You might want to read the papers on the specific simulator we're
> discussing using as a starting point; you can find the white paper on
> Virtutech's web site.  Under the covers, of course, it's probably
> checkpoint based.  But it's efficient, automatic checkpointing such
> that it can provide a reversible view over useful periods of time.
> Complete with "HW savvy" details.

- Thank you.