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