This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: [FYI] tutorial for process record and reverse debugging
> -----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