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>
- Cc: Dan Shearer <dan at shearer dot org>,<gdb at sources dot redhat dot com>
- Date: Sat, 21 May 2005 10:13:04 -0400
- Subject: Re: [discuss] Support for reverse-execution
> 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.