Re: [discuss] Support for reverse-execution

[Paul Schlie <schlie@comcast.net>]

> From: Daniel Jacobowitz <drow@false.org>
>> On Fri, May 20, 2005 at 06:01:44PM -0400, Paul Schlie wrote:
>>> From: Dan Shearer <dan@shearer.org>
>>> In the longer term yes, GDB should be able to debug with a sense of
>>> direction and time. But I think it will take quite a bit of experimentation
>>> before we have a clear model of how to do this, and the only way I can think
>>> of for both having a reversible GDB and not touching GDB too much is by
>>> considering remote targets first.
>> 
>> - Then you'll end up with nothing more than an interface to a propriety
>>   simulator, which doesn't seem like a good goal or approach for GDB.
> 
> This argument is so bogus that I need to call you on it.  You end up
> with a reasonable interface to _any_ simulator, whether proprietary or
> not.  The details of an efficient implementation will be obviously
> dependent on the simulator's state and implementation.

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

> I am inclined to agree with the posted proposals that the
> implementation of reverse-stepi should be opaque to GDB, at least for
> now.  The performance of shuffling state diffs over the remote protocol
> - or even just references to them - would be horrid.  It also means
> that GDB will be limited to a particular class of implementations of
> reversible simulation instead of the concept of reversible simulation.

- There's no magic, defining a interface for a non-existent simulator
  doesn't yield a functional solution, and given the absents of knowledge
  of what that the "typical" simulator's interface presumptions are seems
  a little premature to define in lieu of a solution.

  As an aside and personal opinion, I happen believe it's not likely good
  form to define "opaque" interfaces to non-FSF tools without at least
  simultaneously implementing a non-opaque/proprietary solution (which is
  I guess the same philosophical problem that I have with the sourcing of
  any information, including potentially proprietary extended register/ISA
  definitions through an "opaque" interface/wall).
  
> You're describing something which may be interesting, someday.  Do feel
> welcome to implement it; we'll be glad to help.  I don't think that
> it's inherently more appropriate than the proposed interface, though.

- It was just offered as a potential alternative based on a different
  philosophical view; which I may consider doing something with as time
  and inclination may allow, and do appreciate the offer for assistance
  if/when that time comes.