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

[Marc Khouzam <marc dot khouzam at ericsson dot com>]

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

I just wanted to clarify what I meant.
I agree with you that the behavior you describe is probably the most
useful one.
But I was thinking of certain cases, most probably very rare, such as:
I have a client/server setup where my server answers simple queries;
when running the client in the debugger I would find it useful to
execute the sending of a query, then go backwards and (intead of
replaying "neutered") go forwards again and re-send the query.
The idea here is that I'm more testing my server than my client
by doing this.
Granted, this example is pretty simplistic and probably not that
useful, but I just thought it illustrated that some users may
want to not use replay but instead re-execute.  So it may be nice
to have a command to do that, or a 'mode' that always did that.

Marc