This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Marc Khouzam wrote:

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.

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.


   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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]