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:


[...]
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").

I'm not completely sure of the behaviour of process record here, but
UndoDB in replay mode is completely "neutered", in that the results of
all system calls are 'synthesised'. So if, say, in record mode your
program unlinks a file, then in replay mode the fact the filename is no
longer present on the filesystem doesn't matter - we don't really do an unlink, we just replay the results of whatever unlink returned when in record mode.


I *believe* process record does the same, as would any reasonably sane
reversible debugging approach.   If you can step back over an
instruction, you do so without actually executing the instructions in
question.  So it seems reasonable that in replay mode you can also step
forwards, but without actually executing the instruction.


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.

I agree this would be very useful for the user.



2- we could define a set of behaviors or modes for these scenarios record mode auto record mode replay record mode execute ...

Yes, that should work. I can see giving the user the ability to tweak
it would help. I think the default should be to stop, but what the default is could always be overridden by the frontend.


Greg
--
Greg Law, Undo Software                       http://undo-software.com/


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