Re: [FYI] tutorial for process record and reverse debugging

[Michael Snyder <msnyder@vmware.com>]

Marc Khouzam wrote:

>> OK, so good discussion.  Let's cover some bases here.
>>
>> 1) I'm in record mode, and I want to stay in record mode.
>> No brainer -- that's the default behavior.
>>
>> 2) I'm in record mode, and I want to go to replay mode.
>> Currently the only way to do that is to give a "reverse"
>> command (reverse step, reverse continue...)
>>
>> That's not too bad, but sometimes I might want to simply
>> go to the beginning of the log and start replaying forward
>> from the beginning (ie. not backwards from the end.
>> Or, I might even want to goto the middle before I start
>> to replay (in either direction).
>>
>> We can do that now by using breakpoints, but we might have
>> to disable other breakpoints, if there are any.
> 
> And for long executions, jumping in the recorded log is probably
> faster than using breakpoints.  I agree that this seem valuable.
> 
>> But we COULD do it if we had a command like "goto beginning",
>> or "goto bookmark 12".
> 
> Again, this seems neat.  I do think it is somewhat of an
> 'advanced' feature, as it requires more understanding of PRecord
> than using breakpoints and reverse-continue/reverse-step/etc
> 
>> 3) I'm in replay mode, possibly in the middle of the recording,
>> and I want to switch to record mode.  Now there are several
>> branching possibilities:  Do I want to:
>>
>>    a) Go to the end and start appending to the existing log?
> 
> I can understand someone wanting this.
> 
>>    b) Truncate the existing log at the point where I am, and
>>       start appending to the prefix?
> 
> I never thought of this case.  I see now that for non-deterministic
> executions this could have value.

Not just that, though.  This is also what happens if we
change a memory or register value, eg. a variable that
controls a conditional branch.  We auto-delete the trailing
part of the execution log, because now we're going to go
forward in a different direction.


>>    c) Discard the existing log and start a new log from the
>>       point where I am?
> 
> I think this one is simply to re-issue the 'record' command.
> Also, besides saving some space, I don't really see a big value
> compared to point b) above.

It's a minor case (because it's easy).  I'm just being
exhaustive.

[...]
> Now, let me describe the case I am imagining.
> It is as simple as it gets.
> The user simply enables the 'reverse debugging' feature.
> After that, the user should not need to pay attention to
> record logs and such.  What they should see is that they
> can go forward or backwards as if everything was true 'execution'.
> We don't need to differentiate between 'execution' and 'replay'.
> 
> For example, when changing memory, the user doesn't need to know
> that we are moving away from replay into a new execution.  All 
> they see is that the program moves forward with the new memory
> value.
> 
> And that is why, in this scenario, I thought it seemed
> unintuitive to stop execution when
> arriving at the end of the replay log; instead, the user
> pressed 'continue' and the 'execution' should continue until
> a breakpoint or the end of the program, as if a true execution.
> 
> The only limitation to this, is that we cannot go backwards
> past the start of the recording.  But I think this can be easily
> understood by the user.
> 
> I don't think this scenario is good for everyone, but I think
> for average users, it makes reverse debugging very fluid.

I think that's a great scenario -- just not the only scenario.
We could call that Marc-mode, for devel purposes.   ;-)

How would you suggest we might turn on Marc-mode with a
single command?

Or do you imagine it being the default?