Re: [discuss] Support for reverse-execution

[Paul Schlie <schlie@comcast.net>]

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

- Actually I have intimate familiarity with simulation architecture and
  check-pointed reversible simulation.

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

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

- I've basically already described how to do this in a generalized way.

>> More specifically, as ISA semantics do not generally have deterministic
>> reciprocal semantics,
> 
> What do you mean by "ISA" in this context?

- The sum total of all defined instructions semantic effects on machine
  and program data memory state.

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

- What's interesting is that "reverse" execution is actually very simple,
  once it's understood that you can't generally "reverse execute", but only
  back-up to a previous state; then it becomes clear that all that's
  necessary is to define a method by which state-differences are extracted,
  and then unwound, on an command by command basis, not dissimilarly to how
  "undo" is typically handled by text editors, etc. (one may try to do
  fancier things, but will be found not to likely be worth it.)

>> - (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?

- How about simply defining that the diff-address/diff-extent/diff-values be
  recorded in an indexed file for any differences found between the previous
  memory state, and the now current memory state; where the previous memory
  state is stored in a sequential file, and the present is obtained from the
  target, then computing the diff, and saving the current memory state in
  the file replacing the previously defined previous memory state.

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

- It may be a lot of memory, but it's just a diff between two sequential
  data streams (as roughly described above if done by bruit force; which is
  likely fine for many embedded targets; and the only option if it's not a
  "simulated" target).