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: Fri, 20 May 2005 21:41:58 -0400
- Subject: Re: [discuss] Support for reverse-execution
> From: Daniel Jacobowitz <drow@false.org>
>> On Fri, May 20, 2005 at 06:42:45PM -0400, Paul Schlie wrote:
>> - Which is fully your right to claim/believe; however noting the absence
>> of non-proprietary simulators with these capabilities (it's a little
>> unclear how one can presume that interfaces are likely most ideally
>> necessary or appropriate; and simply note that register and memory state
>> by definition is program state, which GDB already has direct access to).
>
> That is incorrect. There can be considerably more state. For
> instance, I understand from Dan's explanation that Simics will reply
> external interrupt sources - at the same clock cycles where they would
> otherwise have occurred.
- 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?)
[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.]