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

[Greg Law <glaw@undo-software.com>]

Michael Snyder wrote:
> [...]
>>
>>> 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.

But what would we do about "external state"?

Example, say I'm debugging a web-server, and half way through a 
connection I go back, then truncate the log and start again in a new 
direction.  And clients "mid-session" with the webserver are liable to 
get mighty confused.


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

FWIW, early versions of UndoDB operated in "Marc-mode".  We changed it 
because replay mode and record are quite different, particularly w.r.t. 
to the program's interaction with the outside world. "Silent" transition 
from replay to record mode could be quite confusing/surprising.

Greg

-- 
Greg Law, Undo Software                       http://undo-software.com/