[reverse RFC] Add documentation for process record and replay

[Michael Snyder]

Eli Zaretskii wrote:
>> Date: Wed, 15 Oct 2008 13:50:30 +0800
>> From: teawater <teawater@gmail.com>
>> Cc: gdb-patches@sourceware.org, msnyder@vmware.com
>>
>>>> +When this target is in use, if the next instruction to be executed is in the
>>>> +execution log, @value{GDBN} will debug in replay mode so that all the
>>>> +execution events are taken from the execution log.  Otherwise, @value{GDBN}
>>>> +will debug in record mode and record the execution log while executing
>>>> +normally.
>>> What exactly is the "execution log"?  You talk about "next
>>> instruction", which seems to hint that the log records the machine
>>> instructions executed by the inferior -- is that true?  If so, what
>>> are the "execution events" you mention here -- are they just a synonym
>>> for the "instructions", or are they something else?
>>>
>> "execution log" mean is before a instruction execute, record the
>> values of register and memory that will be change in this instruction
>> to a list.
> 
> So you record the values of registers and memory AND the instruction?
> The frequent use of ``instruction'' and ``insn'' is a clear hint to
> this; if as a matter of fact the instructions are not recorded, we
> should modify the text to eliminate those hints.

Eli, I think the relation is that we will save one log entry
for each instruction executed.  Not necessarily that we save
the instruction itself, but since we do save the PC (it being
part of the state that is changed by executing the instruction),
we always have access to the instruction itself if we want it
(either in memory or in object file).