* [RFA] Process record and replay, 10/10
@ 2008-11-06 7:53 teawater
2008-11-07 14:49 ` Eli Zaretskii
0 siblings, 1 reply; 7+ messages in thread
From: teawater @ 2008-11-06 7:53 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1: Type: text/plain, Size: 280 bytes --]
This patch add document for process record and replay.
2008-11-06 Hui Zhu <teawater@gmail.com>
* gdb.texinfo: Add documentation for process record and replay.
gdb.texinfo | 97 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 97 insertions(+)
[-- Attachment #2: precord-doc.txt --]
[-- Type: text/plain, Size: 4610 bytes --]
--- a/doc/gdb.texinfo
+++ b/doc/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
@@ -4972,6 +4973,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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [RFA] Process record and replay, 10/10
2008-11-06 7:53 [RFA] Process record and replay, 10/10 teawater
@ 2008-11-07 14:49 ` Eli Zaretskii
2008-11-08 4:40 ` teawater
0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2008-11-07 14:49 UTC (permalink / raw)
To: teawater; +Cc: gdb-patches
> Date: Thu, 6 Nov 2008 15:52:30 +0800
> From: teawater <teawater@gmail.com>
>
> This patch add document for process record and replay.
>
> 2008-11-06 Hui Zhu <teawater@gmail.com>
>
> * gdb.texinfo: Add documentation for process record and replay.
Thanks. I have a couple of comments.
> +@chapter Recording programs running message and replay it
I don't understand this phrase. What did you want to say? what does
the word "message" have to do with this feature?
> +@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}.
Is the command "target record" or just "record"? or is the latter an
alias of the former? We need to explain all this in the manual,
because the @item says "target record", while in the last sentence
above you say that the command is "record"
Other than that, this part of the patch is okay.
By the way, I think we need a NEWS entry for this feature.
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [RFA] Process record and replay, 10/10
2008-11-07 14:49 ` Eli Zaretskii
@ 2008-11-08 4:40 ` teawater
2008-11-08 9:25 ` Eli Zaretskii
0 siblings, 1 reply; 7+ messages in thread
From: teawater @ 2008-11-08 4:40 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb-patches
Thanks Eli,
On Fri, Nov 7, 2008 at 22:48, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 6 Nov 2008 15:52:30 +0800
>> From: teawater <teawater@gmail.com>
>>
>> This patch add document for process record and replay.
>>
>> 2008-11-06 Hui Zhu <teawater@gmail.com>
>>
>> * gdb.texinfo: Add documentation for process record and replay.
>
> Thanks. I have a couple of comments.
>
>> +@chapter Recording programs running message and replay it
>
> I don't understand this phrase. What did you want to say? what does
> the word "message" have to do with this feature?
What about "Recording inferior execute log and replay it"?
>
>> +@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}.
>
> Is the command "target record" or just "record"? or is the latter an
> alias of the former? We need to explain all this in the manual,
> because the @item says "target record", while in the last sentence
> above you say that the command is "record"
"target record" is the real command.
"record" is a command call "target record". I want it to be the alias
of "target record"
"rec" is a alias of "record".
What about change "@code{record}" to "@code{target record}"?
>
> Other than that, this part of the patch is okay.
>
> By the way, I think we need a NEWS entry for this feature.
>
What about add this:
* Process record and replay
Record inferior execute log and replay it.
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [RFA] Process record and replay, 10/10
2008-11-08 4:40 ` teawater
@ 2008-11-08 9:25 ` Eli Zaretskii
2008-11-11 5:43 ` teawater
0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2008-11-08 9:25 UTC (permalink / raw)
To: teawater; +Cc: gdb-patches
> Date: Sat, 8 Nov 2008 12:39:44 +0800
> From: teawater <teawater@gmail.com>
> Cc: gdb-patches@sourceware.org
>
> >> +@chapter Recording programs running message and replay it
> >
> > I don't understand this phrase. What did you want to say? what does
> > the word "message" have to do with this feature?
>
> What about "Recording inferior execute log and replay it"?
If this is the intent, then I suggest simply
Recording inferior's execution and replaying it
(The fact that you record execution log is an implementation detail,
and certainly does not need to be stated in the chapter's name.)
> > Is the command "target record" or just "record"? or is the latter an
> > alias of the former? We need to explain all this in the manual,
> > because the @item says "target record", while in the last sentence
> > above you say that the command is "record"
>
> "target record" is the real command.
> "record" is a command call "target record". I want it to be the alias
> of "target record"
> "rec" is a alias of "record".
The aliases should be described in the manual.
> What about change "@code{record}" to "@code{target record}"?
Fine with me.
> > By the way, I think we need a NEWS entry for this feature.
> >
>
> What about add this:
>
> * Process record and replay
>
> Record inferior execute log and replay it.
OK, but I think at least one or two more sentences describing the
feature would be nice.
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [RFA] Process record and replay, 10/10
2008-11-08 9:25 ` Eli Zaretskii
@ 2008-11-11 5:43 ` teawater
2008-11-14 16:04 ` Eli Zaretskii
0 siblings, 1 reply; 7+ messages in thread
From: teawater @ 2008-11-11 5:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb-patches
Thanks Eli.
On Sat, Nov 8, 2008 at 17:23, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 8 Nov 2008 12:39:44 +0800
>> From: teawater <teawater@gmail.com>
>> Cc: gdb-patches@sourceware.org
>>
>> >> +@chapter Recording programs running message and replay it
>> >
>> > I don't understand this phrase. What did you want to say? what does
>> > the word "message" have to do with this feature?
>>
>> What about "Recording inferior execute log and replay it"?
>
> If this is the intent, then I suggest simply
>
> Recording inferior's execution and replaying it
>
> (The fact that you record execution log is an implementation detail,
> and certainly does not need to be stated in the chapter's name.)
>
OK. I will use it.
>> > Is the command "target record" or just "record"? or is the latter an
>> > alias of the former? We need to explain all this in the manual,
>> > because the @item says "target record", while in the last sentence
>> > above you say that the command is "record"
>>
>> "target record" is the real command.
>> "record" is a command call "target record". I want it to be the alias
>> of "target record"
>> "rec" is a alias of "record".
>
> The aliases should be described in the manual.
OK. I will.
>
>> What about change "@code{record}" to "@code{target record}"?
>
> Fine with me.
>
>> > By the way, I think we need a NEWS entry for this feature.
>> >
>>
>> What about add this:
>>
>> * Process record and replay
>>
>> Record inferior execute log and replay it.
>
> OK, but I think at least one or two more sentences describing the
> feature would be nice.
>
What about this:
* Process record and replay
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.
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [RFA] Process record and replay, 10/10
2008-11-11 5:43 ` teawater
@ 2008-11-14 16:04 ` Eli Zaretskii
2008-11-14 16:29 ` teawater
0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2008-11-14 16:04 UTC (permalink / raw)
To: teawater; +Cc: gdb-patches
> Date: Tue, 11 Nov 2008 13:03:04 +0800
> From: teawater <teawater@gmail.com>
> Cc: gdb-patches@sourceware.org
>
> >> > By the way, I think we need a NEWS entry for this feature.
> >> >
> >>
> >> What about add this:
> >>
> >> * Process record and replay
> >>
> >> Record inferior execute log and replay it.
> >
> > OK, but I think at least one or two more sentences describing the
> > feature would be nice.
> >
>
> What about this:
>
> * Process record and replay
>
> 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.
This is fine, but please make 2 minor corrections:
In an architecture environment that supports process record and
replay, a ``process record and replay'' target can record a log of the
process execution, and replay it with both forward and reverse
execute commands.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFA] Process record and replay, 10/10
2008-11-14 16:04 ` Eli Zaretskii
@ 2008-11-14 16:29 ` teawater
0 siblings, 0 replies; 7+ messages in thread
From: teawater @ 2008-11-14 16:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb-patches
On Fri, Nov 14, 2008 at 19:46, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Tue, 11 Nov 2008 13:03:04 +0800
>> From: teawater <teawater@gmail.com>
>> Cc: gdb-patches@sourceware.org
>>
>> >> > By the way, I think we need a NEWS entry for this feature.
>> >> >
>> >>
>> >> What about add this:
>> >>
>> >> * Process record and replay
>> >>
>> >> Record inferior execute log and replay it.
>> >
>> > OK, but I think at least one or two more sentences describing the
>> > feature would be nice.
>> >
>>
>> What about this:
>>
>> * Process record and replay
>>
>> 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.
>
> This is fine, but please make 2 minor corrections:
>
> In an architecture environment that supports process record and
> replay, a ``process record and replay'' target can record a log of the
> process execution, and replay it with both forward and reverse
> execute commands.
>
OK. Thanks.
Hui
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2008-11-14 13:53 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-11-06 7:53 [RFA] Process record and replay, 10/10 teawater
2008-11-07 14:49 ` Eli Zaretskii
2008-11-08 4:40 ` teawater
2008-11-08 9:25 ` Eli Zaretskii
2008-11-11 5:43 ` teawater
2008-11-14 16:04 ` Eli Zaretskii
2008-11-14 16:29 ` teawater
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox