This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]