Re: [discuss] Support for reverse-execution

Paul Schlie
2005-05-20T22:43:01Z

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