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

[Hui Zhu <teawater@gmail.com>]

On Wed, Oct 21, 2009 at 04:05, Michael Snyder <msnyder@vmware.com> wrote:
> 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?
>
>

For current status,  this record still have a lot of limit.  I think
make it to default is not very fit for the current record.

Thanks,
Hui