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

[Marc Khouzam <marc.khouzam@ericsson.com>]

 

> -----Original Message-----
> From: Greg Law [mailto:glaw@undo-software.com] 
> Sent: Tuesday, October 20, 2009 5:01 PM
> To: Michael Snyder
> Cc: Marc Khouzam; 'Hui Zhu'; 'gdb@sourceware.org'
> Subject: Re: [FYI] tutorial for process record and reverse debugging
> 
> 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.

To be honest, I hadn't been dealing with any "external state" much.
But now that you mention it, yes, that would make "auto-mode"
(going from replay to record automatically) confusing.
See below please.
 

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

In cases where the program does interact with the outside world, 
I agree that "auto-mode" could be confusing.  In fact, "record mode"
may not be the one we want in this case either.  For instance, in
some cases I may want to re-execute instructions that affect the outside
world, even if I'm gone backwards.  In this case I would want to use
the recorded  data to go backwards, but never to go forward (never use
"replay mode").

This is giving me two ideas:
1- the frontend (my problem) would benefit in showing to the user if
we are currently "executing" or "replaying".  some minimal support from
GDB would help there.

2- we could define a set of behaviors or modes for these scenarios
record mode auto
record mode replay
record mode execute
...

Thanks

Marc