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

Michael Snyder
2009-10-20T20:12:21Z

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?