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

Marc Khouzam
2009-10-20T00:59:21Z

> (gdb) record goto end
> (gdb) record goto beginning
> (gdb) record goto instruction 12345
> (gdb) record goto bookmark 7
>
> Easy enough to make this command ignore breakpoints watchpoints etc.

This sounds neat. Seems like it has a lot of potential.

> > In the tutorial, around the middle of section
> > "Continue, reverse-continue, and breakpoints"
> > it mentions that after doing some reverse execution, we may be
> > "now ready to resume where we left off".
> >
> > From what I understand this means that the user may decide that she
> > is done with reverse execution and wants to go back to executing
> > the live program. To do this, we need to disable all bps, do a
> > 'continue' and then (optionally) re-enable all bps.
> >
> > If going straight to the end of the recording log is a valuable
> > feature, I was thinking it may deserve its own command.
> >
> > Ultimately, I'm hoping that with such a command, we can then see
> > if we can have PRecord directly jump from recorded execution
> > to live execution without stopping.
> >
> > I'm hoping to get opinions from you experts, as I'm not sure it is
> > a good idea.
>
> 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.

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

> d) Go back to the beginning, discard the existing log, and
> start a new log from the beginning?

I think this is
run
record

In Eclipse we have a 'restart' button that calls the 'run' command
and we have a way to automatically turn on 'record' if the user wants.
So that is one feature the frontend can do without gdb support
(I don't believe that is the case for any other scenarios you brought
up).

> These are all things that I think we can do at present, but
> not generally with a single command. Maybe we should kick
> them around. They're all useful, and not far out of reach.
> They wouldn't, for instance, require that we keep several
> branching logs around at the same time (although just think
> what would be possible if we could do that!!! <g>)

Wow, that would be something to see. The UI stuff might
be tricky though.

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.

Thoughts?

Marc