Re: [discuss] Support for reverse-execution

[Dan Shearer <dan@shearer.org>]

On Fri, May 20, 2005 at 11:49:08AM -0400, Paul Schlie wrote:
> Rather than... presume the intelligence need be "remote" to GDB;
    :
> I wonder if it may be more sensible to consider initially defining the basic
> generic facilities by which GDB may directly support undoable/reversible
> execution, and checkpoint features.

An alternative point of view: right now nobody has deep experience with
reversible debugging and so it seems a little early to make
across-the-board structure changes based on limited understanding.

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.

In general I really like the idea of GDB better catering to non-remote
simulators. You'll notice that almost none of the whole-system
simulators in the free software world have integrated debugging and I'd
love to make that easier. It's just that the reversibility property is
new and I think it will take some getting used to.

> More specifically, as ISA semantics do not generally have deterministic
> reciprocal semantics, 

What do you mean by "ISA" in this context?

> Therefore it seems likely sufficient to initially begin by defining
> support for the following core facilities:
> 
> Basic GDB support for check pointing and reverse execution:
> 
> - enable-checkpoints: initializes machine state and program memory to
>   all 0's upon prior to program startup/initialization. (see below)

Isn't this getting out of scope for GDB's current design? If you're
going to provide this meta-system command to the simulator why not
provide others, like "load-image-file <filename>" to initialise the
simulator or "enable-skip-idle" to make the simulator skip idle loops
and other simulator-specific commands.

Again, I like the idea of making GDB closer to simulated environments,
but I think it probably needs to be a specific choice to do this rather
than just as a byproduct of supporting reversibility.

> - (step, next, etc.): as normal, but requests the state-diff from the
>   target stub between successive command executions if reverse-execution
>   flag is enabled. (This may also be supported without target stub support
>   for state-diff, as GDB has direct access to both the target's machine
>   state, and memory state; although target stubs may likely be capable
>   of more efficient diff's if they are capable of tracking memory updates
>   more efficiently than simply looking after the fact.)

Can you explain what kind of a facility you imagine GDB might have to
support doing diffs inherently?

> Basic Target stub facilities to improve reverse execution efficiently:
> 
> - state-diff: the target returns the diff between the target's present
>   state and it's previous state, which may be used if available in lieu
>   of GDB directly calculating machine and memory state diffs, but would
>   likely only be substantially more efficient if the target stub were
>   capable of more efficiently tracking and accumulating diffs by directly
>   monitoring memory state changes, rather than determining them after
>   the fact, as may be done likely efficiently by a target simulator and
>   then simply communicated by publishing the cumulative diffs as requested
>   by GDB; which seems nice and simple, and minimally invasive.)

Unless I've misunderstood you are proposing that GDB have the ability to
accept and manipulate entire memory state and diffs of memory state.
This is quite a large chunk of new functionality.

-- 
Dan Shearer
dan@shearer.org