[reverse RFC] Add documentation for process record and replay

[reverse RFC] Add documentation for process record and replay

[teawater]

[-- Attachment #1: Type: text/plain, Size: 170 bytes --]

Hi Michael,

This patch add doc to gdb.texinfo.

2008-10-14  Hui Zhu  <teawater@gmail.com>

	* gdb.texinfo: Add documentation for process record and replay.

Thanks,
Hui

[-- Attachment #2: rec_doc.txt --]
[-- Type: text/plain, Size: 4690 bytes --]

--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2008-10-14  Hui Zhu  <teawater@gmail.com>
+
+	* gdb.texinfo: Add documentation for process record and replay.
+
 2008-09-30  Michael Snyder  <msnyder@vmware.com>
 
 	* gdb.texinfo: Add documentation for reverse execution.
--- a/gdb.texinfo
+++ b/gdb.texinfo
@@ -144,6 +144,7 @@ software in general.  We will miss him.
 * Running::                     Running programs under @value{GDBN}
 * Stopping::                    Stopping and continuing
 * Reverse Execution::           Running programs backward
+* Process record and replay::   Recording programs running message and replay it
 * Stack::                       Examining the stack
 * Source::                      Examining source files
 * Data::                        Examining data
@@ -4963,6 +4964,96 @@ This is the default.
 @end table
 
 
+@node Process record and replay
+@chapter Recording programs running message and replay it
+@cindex process record and replay
+@cindex recording programs running message and replay it
+
+In a architecture environment that supports process record and replay,
+process record and replay target can record a log of the process execution,
+and replay it with both forward and reverse execute commands.
+
+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.
+
+If you are debugging in a architecture environment that supports
+process record and replay, @value{GDBN} provides the following commands.
+
+@table @code
+@kindex target record
+@kindex record
+@kindex rec
+@item target record
+This a standard command to start process record and replay target.
+Process record and replay target can only debug a process that already
+running. Therefore you need to first start the process @code{run},
+and then start the recording @code{record}.
+
+@kindex stoprecord
+@kindex sr
+@item stoprecord
+Stop process record and replay target at once. When Process record and
+replay target stops, all the execution log will be deleted and the inferior
+will either be terminated, or remain in its final state.
+
+When you stop the process record and replay target in record mode (at the
+end of the execution log), the inferior will be stopped at the next
+instruction that would have been recorded. In other words, if you record
+for a while and then stop recording, the inferior process will be left in
+the same state as if you had never done any recording.
+
+On the other hand, if the process record and replay target is stopped while
+in replay mode (that is, not at the end of the execution log but at some
+earlier point), the inferior process will become "live" at that earlier state,
+and it will then be possible to continue debugging the process "live" from
+that state.
+
+When the inferior process exits, or @value{GDBN} detaches from it, process
+record and replay target will automatically stop itself.
+
+@kindex set record-auto-delete
+@item set record-auto-delete
+@itemx set record-auto-delete 1
+Set the behavior when record instructions limit is reached. 1 mean that GDB
+will auto delete the oldest record to make room for each new one.
+
+@item set record-auto-delete 0
+0 is the default value, meaning that @value{GDBN} will stop the inferior.
+
+@kindex show record-auto-delete
+@item show record-auto-delete
+Show the value of record-auto-delete.
+
+@kindex set record-insn-number-max @var{limit}
+@item set record-insn-number-max @var{limit}
+Set the limit of instructions to be recorded.  Default value is 200000.
+If set to 0, record instructions number limit function will disable.
+In this case, if record instructions number is bigger than @var{limit},
+@value{GDBN} will auto delete the earliest recorded instruction to make room
+for each new one.
+
+@kindex show record-insn-number-max
+@item show record-insn-number-max
+Show the value of recorded instructions limit.
+
+@kindex info record-insn-number
+@item info record-insn-number
+Show the current number of recorded instructions.
+
+@kindex delrecord
+@kindex dr
+@item delrecord
+When record target running in replay mode ("in the past"), delete the
+subsequent execution log and begin to record a new execution log starting
+from the current address. This has much the same effect as "changing the past"
+(see "Set values of variables", above); it means you will abandon the
+previously recorded "future" and begin recording a new "future".
+@end table
+
+
 @node Stack
 @chapter Examining the Stack
 

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

[Eli Zaretskii]

> Date: Tue, 14 Oct 2008 23:00:59 +0800
> From: teawater <teawater@gmail.com>
> 
> This patch add doc to gdb.texinfo.
> 
> 2008-10-14  Hui Zhu  <teawater@gmail.com>
> 
> 	* gdb.texinfo: Add documentation for process record and replay.

Thank you.  I have a few questions and suggestions about this.

> +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?

> +Process record and replay target can only debug a process that already
> +running. Therefore you need to first start the process @code{run},
> +and then start the recording @code{record}.

This is really inconvenient, because it means the beginning of the
program's execution cannot be recorded.  Is that a limitation, or am I
missing something?

This:

> +@item stoprecord
> +Stop process record and replay target at once. When Process record and
> +replay target stops, all the execution log will be deleted and the inferior
> +will either be terminated, or remain in its final state.

and this:

> +When you stop the process record and replay target in record mode (at the
> +end of the execution log), the inferior will be stopped at the next
> +instruction that would have been recorded.

seem to be in contradiction: the former says that the inferior will be
terminated, the latter says that it will be stopped.  Which one is it?

>                                              In other words, if you record
> +for a while and then stop recording, the inferior process will be left in
> +the same state as if you had never done any recording.

Why is this sentence important?  Recording has no side effects except
for the recorded information, so why did you need to say that the
inferior will be left in a state ``as if recording never happened''?

> +@itemx set record-auto-delete 1
> +Set the behavior when record instructions limit is reached. 1 mean that GDB
> +will auto delete the oldest record to make room for each new one.
> +
> +@item set record-auto-delete 0
> +0 is the default value, meaning that @value{GDBN} will stop the inferior.

Either the name of the option or the argument should be modified,
IMO.  I prefer to rename the option (to something like
record-stop-at-limit, and change the default to 1).

Also, there's a relation between this option and
record-insn-number-max, right?  If so, the text should mention that.

> +@item set record-insn-number-max @var{limit}
> +Set the limit of instructions to be recorded.  Default value is 200000.
> +If set to 0, record instructions number limit function will disable.
> +In this case, if record instructions number is bigger than @var{limit},
> +@value{GDBN} will auto delete the earliest recorded instruction to make room
> +for each new one.

I think you need to transpose the two last sentences, otherwise the
text seems to say that when the limit is set to zero, GDB will delete
earliest instruction when the (zero) limit is exhausted.

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

[teawater]

Hi Eli,

On Wed, Oct 15, 2008 at 00:33, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Tue, 14 Oct 2008 23:00:59 +0800
>> From: teawater <teawater@gmail.com>
>>
>> This patch add doc to gdb.texinfo.
>>
>> 2008-10-14  Hui Zhu  <teawater@gmail.com>
>>
>>       * gdb.texinfo: Add documentation for process record and replay.
>
> Thank you.  I have a few questions and suggestions about this.
>

Thanks for your questions and suggestions. All of them are very good.

>> +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. This list is called "execution log".
In replay mode, inferior will not execute actually. It will just
execute in GDB itself. So this called "execution events".

I am trying to talk clear this in a internal doc that I am writing.


>> +Process record and replay target can only debug a process that already
>> +running. Therefore you need to first start the process @code{run},
>> +and then start the recording @code{record}.
>
> This is really inconvenient, because it means the beginning of the
> program's execution cannot be recorded.  Is that a limitation, or am I
> missing something?

Cause P record will record the values before instruction execute. So
it can't work before program's begin.
And I don't think we need it. Cause most of time, people just care
about program execute after "main". You can set a breakpoint in "main"
and open P record when inferior break in there.
Or if you care about a lot of thing before "main". You can set a
breakpoint in "_start" and open P record when inferior break in there.


>
> This:
>
>> +@item stoprecord
>> +Stop process record and replay target at once. When Process record and
>> +replay target stops, all the execution log will be deleted and the inferior
>> +will either be terminated, or remain in its final state.
>
> and this:
>
>> +When you stop the process record and replay target in record mode (at the
>> +end of the execution log), the inferior will be stopped at the next
>> +instruction that would have been recorded.
>
> seem to be in contradiction: the former says that the inferior will be
> terminated, the latter says that it will be stopped.  Which one is it?

"terminated" is a suggest from Michael. I think it's mean is stop in there.

>
>>                                              In other words, if you record
>> +for a while and then stop recording, the inferior process will be left in
>> +the same state as if you had never done any recording.
>
> Why is this sentence important?  Recording has no side effects except
> for the recorded information, so why did you need to say that the
> inferior will be left in a state ``as if recording never happened''?
>

OK. I will change it.



>> +@itemx set record-auto-delete 1
>> +Set the behavior when record instructions limit is reached. 1 mean that GDB
>> +will auto delete the oldest record to make room for each new one.
>> +
>> +@item set record-auto-delete 0
>> +0 is the default value, meaning that @value{GDBN} will stop the inferior.
>
> Either the name of the option or the argument should be modified,
> IMO.  I prefer to rename the option (to something like
> record-stop-at-limit, and change the default to 1).
>
> Also, there's a relation between this option and
> record-insn-number-max, right?  If so, the text should mention that.
>

I think 0 is better than 1. Cause when GDB stop, it will ask user how
to do stop or set record-auto-delete to 1. I think it's user
experience is better than default to 1. Maybe I need add more
introduce to  record-auto-delete 0.

"record-stop-at-limit" is better. I will change it. :)



>> +@item set record-insn-number-max @var{limit}
>> +Set the limit of instructions to be recorded.  Default value is 200000.
>> +If set to 0, record instructions number limit function will disable.
>> +In this case, if record instructions number is bigger than @var{limit},
>> +@value{GDBN} will auto delete the earliest recorded instruction to make room
>> +for each new one.
>
> I think you need to transpose the two last sentences, otherwise the
> text seems to say that when the limit is set to zero, GDB will delete
> earliest instruction when the (zero) limit is exhausted.
>

I will transpose the two last sentences.

If the limit is set to zero, it will delete nothing. I will add some
introduce to this part.


Thanks,
Hui

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

[Eli Zaretskii]

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

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

[teawater]

On Wed, Oct 15, 2008 at 15:21, Eli Zaretskii <eliz@gnu.org> 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.
>

No, it just record the values of registers and memory, not care about
instruction.

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

[Eli Zaretskii]

> Date: Wed, 15 Oct 2008 15:33:53 +0800
> From: teawater <teawater@gmail.com>
> Cc: gdb-patches@sourceware.org, msnyder@vmware.com
> 
> >> "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.
> >
> 
> No, it just record the values of registers and memory, not care about
> instruction.

Then I think it's really confusing to talk about ``instructions'' in
this context.  At the very least, we should explain what we mean by
``instructions'' in that section.

Can you show me a few examples of the recorded ``instructions''?

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

[teawater]

On Wed, Oct 15, 2008 at 16:14, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 15 Oct 2008 15:33:53 +0800
>> From: teawater <teawater@gmail.com>
>> Cc: gdb-patches@sourceware.org, msnyder@vmware.com
>>
>> >> "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.
>> >
>>
>> No, it just record the values of registers and memory, not care about
>> instruction.
>
> Then I think it's really confusing to talk about ``instructions'' in
> this context.  At the very least, we should explain what we mean by
> ``instructions'' in that section.
>
> Can you show me a few examples of the recorded ``instructions''?
>

OK.
For example, x86 instruction "nop". It not change anything except $eip
(x86 pc reg).
Then, record $eip current value. That's all.

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

[Eli Zaretskii]

> Date: Wed, 15 Oct 2008 16:40:44 +0800
> From: teawater <teawater@gmail.com>
> Cc: gdb-patches@sourceware.org, msnyder@vmware.com
> 
> > Can you show me a few examples of the recorded ``instructions''?
> >
> 
> OK.
> For example, x86 instruction "nop". It not change anything except $eip
> (x86 pc reg).
> Then, record $eip current value. That's all.

Thanks.

So you record the value of $pc, in addition to the registers and
memory, if any, that will change, yes?

And what about a more interesting example, like the mov instruction?

Re: [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).

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

[Eli Zaretskii]

> Date: Wed, 15 Oct 2008 11:48:53 -0700
> From: Michael Snyder <msnyder@vmware.com>
> CC: teawater <teawater@gmail.com>, 
>  "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
> 
> 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).

I understand that (now).  But the original text, viz.

  When this target is in use, if the next instruction to be executed
  is in the execution log, ...
  ^^^^^^^^^^^^^^^^^^^^^^^

made it sound like the instructions themselves are in the log.  This
will need to be rephrased.

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

[teawater]

On Thu, Oct 16, 2008 at 03:43, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 15 Oct 2008 11:48:53 -0700
>> From: Michael Snyder <msnyder@vmware.com>
>> CC: teawater <teawater@gmail.com>,
>>  "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
>>
>> 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).
>
> I understand that (now).  But the original text, viz.
>
>  When this target is in use, if the next instruction to be executed
>  is in the execution log, ...
>  ^^^^^^^^^^^^^^^^^^^^^^^
>
> made it sound like the instructions themselves are in the log.  This
> will need to be rephrased.
>

Sorry for understand your mean so slow.

How about change it to "if the next instruction has the execution log for it"?

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

[Eli Zaretskii]

> Date: Thu, 16 Oct 2008 10:09:33 +0800
> From: teawater <teawater@gmail.com>
> Cc: "Michael Snyder" <msnyder@vmware.com>, gdb-patches@sourceware.org
> 
> How about change it to "if the next instruction has the execution log for it"?

I think this is better:

   if the execution log includes the record for the next instruction, ...

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

[teawater]

Great! I will change it.

On Thu, Oct 16, 2008 at 15:01, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 16 Oct 2008 10:09:33 +0800
>> From: teawater <teawater@gmail.com>
>> Cc: "Michael Snyder" <msnyder@vmware.com>, gdb-patches@sourceware.org
>>
>> How about change it to "if the next instruction has the execution log for it"?
>
> I think this is better:
>
>   if the execution log includes the record for the next instruction, ...
>

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

[teawater]

[-- Attachment #1: Type: text/plain, Size: 701 bytes --]

Hi,

According to the suggestions. I make a new patch.

2008-10-16  Hui Zhu  <teawater@gmail.com>

	* gdb.texinfo: Add documentation for process record and replay.

Thanks,
Hui

On Thu, Oct 16, 2008 at 15:04, teawater <teawater@gmail.com> wrote:
> Great! I will change it.
>
> On Thu, Oct 16, 2008 at 15:01, Eli Zaretskii <eliz@gnu.org> wrote:
>>> Date: Thu, 16 Oct 2008 10:09:33 +0800
>>> From: teawater <teawater@gmail.com>
>>> Cc: "Michael Snyder" <msnyder@vmware.com>, gdb-patches@sourceware.org
>>>
>>> How about change it to "if the next instruction has the execution log for it"?
>>
>> I think this is better:
>>
>>   if the execution log includes the record for the next instruction, ...
>>
>

[-- Attachment #2: rec_doc.txt --]
[-- Type: text/plain, Size: 4835 bytes --]

--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2008-10-16  Hui Zhu  <teawater@gmail.com>
+
+	* gdb.texinfo: Add documentation for process record and replay.
+
 2008-09-30  Michael Snyder  <msnyder@vmware.com>
 
 	* gdb.texinfo: Add documentation for reverse execution.
--- a/gdb.texinfo
+++ b/gdb.texinfo
@@ -144,6 +144,7 @@ software in general.  We will miss him.
 * Running::                     Running programs under @value{GDBN}
 * Stopping::                    Stopping and continuing
 * Reverse Execution::           Running programs backward
+* Process record and replay::   Recording programs running message and replay it
 * Stack::                       Examining the stack
 * Source::                      Examining source files
 * Data::                        Examining data
@@ -4963,6 +4964,101 @@ This is the default.
 @end table
 
 
+@node Process record and replay
+@chapter Recording programs running message and replay it
+@cindex process record and replay
+@cindex recording programs running message and replay it
+
+In a architecture environment that supports process record and replay,
+process record and replay target can record a log of the process execution,
+and replay it with both forward and reverse execute commands.
+
+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 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.
+
+If you are debugging in a architecture environment that supports
+process record and replay, @value{GDBN} provides the following commands.
+
+@table @code
+@kindex target record
+@kindex record
+@kindex rec
+@item target record
+This a standard command to start process record and replay target.
+Process record and replay target can only debug a process that already
+running. Therefore you need to first start the process @code{run},
+and then start the recording @code{record}.
+
+@kindex stoprecord
+@kindex sr
+@item stoprecord
+Stop process record and replay target at once. When Process record and
+replay target stops, all the execution log will be deleted and the inferior
+will either be terminated, or remain in its final state.
+
+When you stop the process record and replay target in record mode (at the
+end of the execution log), the inferior will be stopped at the next
+instruction that would have been recorded. In other words, if you record
+for a while and then stop recording, the inferior process will be left in
+the same state as if recording never happened.
+
+On the other hand, if the process record and replay target is stopped while
+in replay mode (that is, not at the end of the execution log but at some
+earlier point), the inferior process will become "live" at that earlier state,
+and it will then be possible to continue debugging the process "live" from
+that state.
+
+When the inferior process exits, or @value{GDBN} detaches from it, process
+record and replay target will automatically stop itself.
+
+@kindex set record-insn-number-max @var{limit}
+@item set record-insn-number-max @var{limit}
+Set the limit of instructions to be recorded.  Default value is 200000.
+
+In this case, if record instructions number is bigger than @var{limit},
+@value{GDBN} will auto delete the earliest recorded instruction execute
+log.
+
+If set to 0, @value{GDBN} will not delete the earliest recorded instruction
+execute log.  Record instructions number limit function will disable.
+
+@kindex show record-insn-number-max
+@item show record-insn-number-max
+Show the value of recorded instructions limit.
+
+@kindex set record-stop-at-limit
+@item set record-stop-at-limit
+@item set record-stop-at-limit on
+Set the behavior when record instructions limit is reached.
+This is the default mode. Meaning that @value{GDBN} will stop ask user
+want close @code{record-stop-at-limit} or stop inferior.
+
+@itemx set record-stop-at-limit off
+This mean that @value{GDBN} will auto delete the oldest record to make
+room for each new one.
+
+@kindex show record-stop-at-limit
+@item show record-stop-at-limit
+Show the value of record-stop-at-limit.
+
+@kindex info record-insn-number
+@item info record-insn-number
+Show the current number of recorded instructions.
+
+@kindex delrecord
+@kindex dr
+@item delrecord
+When record target running in replay mode ("in the past"), delete the
+subsequent execution log and begin to record a new execution log starting
+from the current address. This has much the same effect as "changing the past"
+(see "Set values of variables", above); it means you will abandon the
+previously recorded "future" and begin recording a new "future".
+@end table
+
+
 @node Stack
 @chapter Examining the Stack
 

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

[Eli Zaretskii]

> Date: Thu, 16 Oct 2008 15:35:01 +0800
> From: teawater <teawater@gmail.com>
> Cc: msnyder@vmware.com, gdb-patches@sourceware.org
> 
> According to the suggestions. I make a new patch.
> 
> 2008-10-16  Hui Zhu  <teawater@gmail.com>
> 
> 	* gdb.texinfo: Add documentation for process record and replay.

OK.  This needs some rewording and rephrasing, but I can do that
later, after the patch is committed.  (However, please fix the few
simple formatting errors I mention below.)

I'm somewhat concerned about the fact that the functionality and
limitations of the ``record and replay'' target are not described at
all.  If I were to debug using such an architecture, I'd like to know
what it can and cannot do.  For example, if I replay, does the I/O
happen like it happened during the recorded session?  What about
signals? crashes? etc.  Are there things that simply cannot be
reproduced exactly, due to fundamental limitations of the replay
target?

Shouldn't we give the reader some idea about these issues?

> +running. Therefore you need to first start the process @code{run},
          ^^
Please make sure you have 2 spaces after each period that ends a
sentence.

> +earlier point), the inferior process will become "live" at that earlier state,
> +and it will then be possible to continue debugging the process "live" from
> +that state.

``live'', not "live".  In Texinfo, please always use ``...'' quoting
rather than "..", because the former produces prettier results in the
printed manual.  ".." should be reserved only for string constants in
code fragments.

> +@kindex set record-insn-number-max @var{limit}

Please don't put arguments in the index entries.  Index entries should
name only the command name.

> +@item set record-stop-at-limit
> +@item set record-stop-at-limit on

Only the first item of several that share the same description can use
@item, the rest should use @itemx.

> +@itemx set record-stop-at-limit off

@itemx cannot be the first item.

> +(see "Set values of variables", above); it means you will abandon the

Is this a reference to another section?  If so, please use @pxref,
which will produce a true hyperlink that can be followed in an Info
reader.

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

[teawater]

[-- Attachment #1: Type: text/plain, Size: 2504 bytes --]

Thanks Eli.
I make a new one.

2008-10-17  Hui Zhu  <teawater@gmail.com>

	* gdb.texinfo: Add documentation for process record and replay.

Thanks,
Hui

On Fri, Oct 17, 2008 at 02:40, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 16 Oct 2008 15:35:01 +0800
>> From: teawater <teawater@gmail.com>
>> Cc: msnyder@vmware.com, gdb-patches@sourceware.org
>>
>> According to the suggestions. I make a new patch.
>>
>> 2008-10-16  Hui Zhu  <teawater@gmail.com>
>>
>>       * gdb.texinfo: Add documentation for process record and replay.
>
> OK.  This needs some rewording and rephrasing, but I can do that
> later, after the patch is committed.  (However, please fix the few
> simple formatting errors I mention below.)
>
> I'm somewhat concerned about the fact that the functionality and
> limitations of the ``record and replay'' target are not described at
> all.  If I were to debug using such an architecture, I'd like to know
> what it can and cannot do.  For example, if I replay, does the I/O
> happen like it happened during the recorded session?  What about
> signals? crashes? etc.  Are there things that simply cannot be
> reproduced exactly, due to fundamental limitations of the replay
> target?
>
> Shouldn't we give the reader some idea about these issues?
>
>> +running. Therefore you need to first start the process @code{run},
>          ^^
> Please make sure you have 2 spaces after each period that ends a
> sentence.
>
>> +earlier point), the inferior process will become "live" at that earlier state,
>> +and it will then be possible to continue debugging the process "live" from
>> +that state.
>
> ``live'', not "live".  In Texinfo, please always use ``...'' quoting
> rather than "..", because the former produces prettier results in the
> printed manual.  ".." should be reserved only for string constants in
> code fragments.
>
>> +@kindex set record-insn-number-max @var{limit}
>
> Please don't put arguments in the index entries.  Index entries should
> name only the command name.
>
>> +@item set record-stop-at-limit
>> +@item set record-stop-at-limit on
>
> Only the first item of several that share the same description can use
> @item, the rest should use @itemx.
>
>> +@itemx set record-stop-at-limit off
>
> @itemx cannot be the first item.
>
>> +(see "Set values of variables", above); it means you will abandon the
>
> Is this a reference to another section?  If so, please use @pxref,
> which will produce a true hyperlink that can be followed in an Info
> reader.
>

[-- Attachment #2: rec_doc.txt --]
[-- Type: text/plain, Size: 4867 bytes --]

--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2008-10-17  Hui Zhu  <teawater@gmail.com>
+
+	* gdb.texinfo: Add documentation for process record and replay.
+
 2008-09-30  Michael Snyder  <msnyder@vmware.com>
 
 	* gdb.texinfo: Add documentation for reverse execution.
--- a/gdb.texinfo
+++ b/gdb.texinfo
@@ -144,6 +144,7 @@ software in general.  We will miss him.
 * Running::                     Running programs under @value{GDBN}
 * Stopping::                    Stopping and continuing
 * Reverse Execution::           Running programs backward
+* Process record and replay::   Recording programs running message and replay it
 * Stack::                       Examining the stack
 * Source::                      Examining source files
 * Data::                        Examining data
@@ -4963,6 +4964,102 @@ This is the default.
 @end table
 
 
+@node Process record and replay
+@chapter Recording programs running message and replay it
+@cindex process record and replay
+@cindex recording programs running message and replay it
+
+In a architecture environment that supports process record and replay,
+process record and replay target can record a log of the process execution,
+and replay it with both forward and reverse execute commands.
+
+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.
+
+Otherwise, @value{GDBN} will debug in record mode.  So inferior will
+execute normally and @value{GDBN} will record the execution log.
+
+If you are debugging in a architecture environment that supports
+process record and replay, @value{GDBN} provides the following commands.
+
+@table @code
+@kindex target record
+@kindex record
+@kindex rec
+@item target record
+This a standard command to start process record and replay target.
+Process record and replay target can only debug a process that already
+running.  Therefore you need to first start the process @code{run},
+and then start the recording @code{record}.
+
+@kindex stoprecord
+@kindex sr
+@item stoprecord
+Stop process record and replay target at once. When Process record and
+replay target stops, all the execution log will be deleted and the inferior
+will either be terminated, or remain in its final state.
+
+When you stop the process record and replay target in record mode (at the
+end of the execution log), the inferior will be stopped at the next
+instruction that would have been recorded.  In other words, if you record
+for a while and then stop recording, the inferior process will be left in
+the same state as if recording never happened.
+
+On the other hand, if the process record and replay target is stopped while
+in replay mode (that is, not at the end of the execution log but at some
+earlier point), the inferior process will become ``live" at that earlier state,
+and it will then be possible to continue debugging the process ``live" from
+that state.
+
+When the inferior process exits, or @value{GDBN} detaches from it, process
+record and replay target will automatically stop itself.
+
+@kindex set record-insn-number-max
+@item set record-insn-number-max @var{limit}
+Set the limit of instructions to be recorded.  Default value is 200000.
+
+In this case, if record instructions number is bigger than @var{limit},
+@value{GDBN} will auto delete the earliest recorded instruction execute
+log.
+
+If set to 0, @value{GDBN} will not delete the earliest recorded instruction
+execute log.  Record instructions number limit function will disable.
+
+@kindex show record-insn-number-max
+@item show record-insn-number-max
+Show the value of recorded instructions limit.
+
+@kindex set record-stop-at-limit
+@item set record-stop-at-limit on
+Set the behavior when record instructions limit is reached.
+This is the default mode.  Meaning that @value{GDBN} will stop ask user
+want close @code{record-stop-at-limit} or stop inferior.
+
+@item set record-stop-at-limit off
+This mean that @value{GDBN} will auto delete the oldest record to make
+room for each new one.
+
+@kindex show record-stop-at-limit
+@item show record-stop-at-limit
+Show the value of record-stop-at-limit.
+
+@kindex info record-insn-number
+@item info record-insn-number
+Show the current number of recorded instructions.
+
+@kindex delrecord
+@kindex dr
+@item delrecord
+When record target running in replay mode (``in the past"), delete the
+subsequent execution log and begin to record a new execution log starting
+from the current address.  It means you will abandon the previously
+recorded ``future" and begin recording a new ``future".
+@end table
+
+
 @node Stack
 @chapter Examining the Stack
 

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

[Eli Zaretskii]

> Date: Fri, 17 Oct 2008 11:17:59 +0800
> From: teawater <teawater@gmail.com>
> Cc: msnyder@vmware.com, gdb-patches@sourceware.org
> 
> Thanks Eli.
> I make a new one.

Almost there ;-)

> > I'm somewhat concerned about the fact that the functionality and
> > limitations of the ``record and replay'' target are not described at
> > all.  If I were to debug using such an architecture, I'd like to know
> > what it can and cannot do.  For example, if I replay, does the I/O
> > happen like it happened during the recorded session?  What about
> > 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?

> +Stop process record and replay target at once. When Process record and
                                                ^^
Still one space.

> +earlier point), the inferior process will become ``live" at that earlier state,

``live'', not ``live".  (There are more cases of this in the text.)

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

[teawater]

On Fri, Oct 17, 2008 at 18:06, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 17 Oct 2008 11:17:59 +0800
>> From: teawater <teawater@gmail.com>
>> Cc: msnyder@vmware.com, gdb-patches@sourceware.org
>>
>> Thanks Eli.
>> I make a new one.
>
> Almost there ;-)
>
>> > I'm somewhat concerned about the fact that the functionality and
>> > limitations of the ``record and replay'' target are not described at
>> > all.  If I were to debug using such an architecture, I'd like to know
>> > what it can and cannot do.  For example, if I replay, does the I/O
>> > happen like it happened during the recorded session?  What about
>> > 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 had added some introduce after "@cindex recording programs running
message and replay it".

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.

>
>> +Stop process record and replay target at once. When Process record and
>                                                ^^
> Still one space.
>
>> +earlier point), the inferior process will become ``live" at that earlier state,
>
> ``live'', not ``live".  (There are more cases of this in the text.)
>

Thanks, I will fix them.

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

[Jakob Engblom]

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

Best regards,

/jakob

_______________________________________________________

Jakob Engblom, PhD, Technical Marketing Manager

Virtutech                   Direct: +46 8 690 07 47    
Drottningholmsvägen 14      Mobile: +46 709 242 646   
11243 Stockholm             Web:    www.virtutech.com  
Sweden
________________________________________________________
 

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

[Michael Snyder]

Jakob Engblom wrote:
>>>> 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.

Absolutely.  But here, we are discussing the documentation for
one particular mechanism, what we're referring to as "process
record and replay".  This only records and replays the execution
of a single process, so it might be a good idea to document its
specific capabilities and limitations in this area.

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

[Eli Zaretskii]

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

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

[teawater]

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

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

[teawater]

Replay mode is designed to replay the inferior execute behaver (Now,
it just care about registers and memory change. It will add more in
the future) in before.

So it don't replay what you were talk about.

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

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

[teawater]

[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]

Hi Eli,

I make a patch for doc.

2008-10-22  Hui Zhu  <teawater@gmail.com>

	* gdb.texinfo: Add documentation for process record and replay.

Thanks,
Hui

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

[-- Attachment #2: rec_doc.txt --]
[-- Type: text/plain, Size: 4602 bytes --]

--- a/gdb.texinfo
+++ b/gdb.texinfo
@@ -144,6 +144,7 @@ software in general.  We will miss him.
 * Running::                     Running programs under @value{GDBN}
 * Stopping::                    Stopping and continuing
 * Reverse Execution::           Running programs backward
+* Process record and replay::   Recording programs running message and replay it
 * Stack::                       Examining the stack
 * Source::                      Examining source files
 * Data::                        Examining data
@@ -4963,6 +4964,102 @@ This is the default.
 @end table
 
 
+@node Process record and replay
+@chapter Recording programs running message and replay it
+@cindex process record and replay
+@cindex recording programs running message and replay it
+
+In a architecture environment that supports process record and replay,
+process record and replay target can record a log of the process execution,
+and replay it with both forward and reverse execute commands.
+
+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.
+
+Otherwise, @value{GDBN} will debug in record mode.  So inferior will
+execute normally and @value{GDBN} will record the execution log.
+
+If you are debugging in a architecture environment that supports
+process record and replay, @value{GDBN} provides the following commands.
+
+@table @code
+@kindex target record
+@kindex record
+@kindex rec
+@item target record
+This a standard command to start process record and replay target.
+Process record and replay target can only debug a process that already
+running.  Therefore you need to first start the process @code{run},
+and then start the recording @code{record}.
+
+@kindex stoprecord
+@kindex sr
+@item stoprecord
+Stop process record and replay target at once.  When Process record and
+replay target stops, all the execution log will be deleted and the inferior
+will either be terminated, or remain in its final state.
+
+When you stop the process record and replay target in record mode (at the
+end of the execution log), the inferior will be stopped at the next
+instruction that would have been recorded.  In other words, if you record
+for a while and then stop recording, the inferior process will be left in
+the same state as if recording never happened.
+
+On the other hand, if the process record and replay target is stopped while
+in replay mode (that is, not at the end of the execution log but at some
+earlier point), the inferior process will become ``live'' at that earlier state,
+and it will then be possible to continue debugging the process ``live'' from
+that state.
+
+When the inferior process exits, or @value{GDBN} detaches from it, process
+record and replay target will automatically stop itself.
+
+@kindex set record-insn-number-max
+@item set record-insn-number-max @var{limit}
+Set the limit of instructions to be recorded.  Default value is 200000.
+
+In this case, if record instructions number is bigger than @var{limit},
+@value{GDBN} will auto delete the earliest recorded instruction execute
+log.
+
+If set to 0, @value{GDBN} will not delete the earliest recorded instruction
+execute log.  Record instructions number limit function will disable.
+
+@kindex show record-insn-number-max
+@item show record-insn-number-max
+Show the value of recorded instructions limit.
+
+@kindex set record-stop-at-limit
+@item set record-stop-at-limit on
+Set the behavior when record instructions limit is reached.
+This is the default mode.  Meaning that @value{GDBN} will stop ask user
+want close @code{record-stop-at-limit} or stop inferior.
+
+@item set record-stop-at-limit off
+This mean that @value{GDBN} will auto delete the oldest record to make
+room for each new one.
+
+@kindex show record-stop-at-limit
+@item show record-stop-at-limit
+Show the value of record-stop-at-limit.
+
+@kindex info record-insn-number
+@item info record-insn-number
+Show the current number of recorded instructions.
+
+@kindex delrecord
+@kindex dr
+@item delrecord
+When record target running in replay mode (``in the past''), delete the
+subsequent execution log and begin to record a new execution log starting
+from the current address.  It means you will abandon the previously
+recorded ``future'' and begin recording a new ``future''.
+@end table
+
+
 @node Stack
 @chapter Examining the Stack
 

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

[Eli Zaretskii]

> Date: Wed, 22 Oct 2008 10:38:37 +0800
> From: teawater <teawater@gmail.com>
> Cc: msnyder@vmware.com, gdb-patches@sourceware.org
> 
> I make a patch for doc.
> 
> 2008-10-22  Hui Zhu  <teawater@gmail.com>
> 
> 	* gdb.texinfo: Add documentation for process record and replay.

OK.  Thanks.

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

[teawater]

Thanks Eli. I have checked it in.

Hui

On Thu, Oct 23, 2008 at 03:50, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 22 Oct 2008 10:38:37 +0800
>> From: teawater <teawater@gmail.com>
>> Cc: msnyder@vmware.com, gdb-patches@sourceware.org
>>
>> I make a patch for doc.
>>
>> 2008-10-22  Hui Zhu  <teawater@gmail.com>
>>
>>       * gdb.texinfo: Add documentation for process record and replay.
>
> OK.  Thanks.
>