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

[Michael Snyder <msnyder at vmware dot com>]

Greg Law wrote:
> 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"?

Well, I had only been talking in the context of process record,
which doesn't really deal all that well with external state,
as far as I know.

It's fine to open up the discussion to general reverse debugging,
but I think at some point different implementations are going to
have to have their own separate, dedicated commands (as process
record presently does).

Of course, the more generality, the better!


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

Speaking only for process record, I don't think process record
could handle that situation well.  It's called process record
for one reason because it only handles one process at a time
(in fact, currently only one thread at a time).