Re: [reverse RFC] Add documentation for process record and replay

[teawater <teawater at gmail dot com>]

OK! Please talk around the my doc.

When this target is in use, if the execution log includes the record for
the next instruction, @value{GDBN} will debug in replay mode.  So inferior
will not really execute and all the execution events are taken from the
execution log.  Just the values of registers (include pc register) and
memory of the inferior will be changed.

On Sat, Oct 18, 2008 at 03:47, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: "Jakob Engblom" <jakob@virtutech.com>
>> Cc: <msnyder@vmware.com>,
>>       <gdb-patches@sourceware.org>
>> Date: Fri, 17 Oct 2008 21:31:36 +0200
>>
>> > > > signals? crashes? etc.  Are there things that simply cannot be
>> > > > reproduced exactly, due to fundamental limitations of the replay
>> > > > target?
>> >
>> > Do you have an opinion about these concerns?
>>
>> I would like to jump in here and point out that this will depend on the nature
>> of the target.  Simics, and presumably other full-system simulation solutions,
>> can replay the entire IO of a machine.  This includes any external IO that is
>> asynch to the simulator execution (such as network packets and user input).
>> Between machines in a simulated network of machines, replay is obviously
>> perfect.
>>
>> If you try to do this on a live machine, it is a bit more tricky.
>>
>> So this is best left to the underlying mechanism, in my experience.
>
> We should at least describe a couple of possibilities and tell the
> reader to consult the documentation of the particular target for the
> full details.
>