From: Hui Zhu <teawater@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: msnyder@vmware.com, gdb-patches@sourceware.org
Subject: Re: [RFA/RFC] Add dump and load command to process record and replay
Date: Mon, 31 Aug 2009 07:10:00 -0000 [thread overview]
Message-ID: <daef60380908301951m392aca0jccf3283f124066dd@mail.gmail.com> (raw)
In-Reply-To: <83skf99ob0.fsf@gnu.org>
On Mon, Aug 31, 2009 at 01:58, Eli Zaretskii<eliz@gnu.org> wrote:
>> From: Hui Zhu <teawater@gmail.com>
>> Date: Sun, 30 Aug 2009 11:20:32 +0800
>> Cc: Michael Snyder <msnyder@vmware.com>, gdb-patches@sourceware.org
>>
>> > This all needs to be said in the manual (in a form suitable for the
>> > manual, omitting the technicalities and describing this from user
>> > perspective). We cannot just say "dump record log to core file". So
>> > I hereby revoke my approval of the patch for the manual.
>> >
>>
>> Agree with you, Eli. Do you have more better words on it? You know
>> my poor english. :)
>
> Something like this:
>
> @kindex record dump
> @kindex rec dump
> @item record dump [@var{file}]
> @itemx rec dump [@var{file}]
> Dump the execution records of the inferior process to the named
> @var{file}. If not specified, @var{file} defaults to
> @file{gdb_record.@var{pid}}, where @var{pid} is is the PID of the
> inferior process.
>
> The file created by this command is actually a kind of core file,
> with an extra section that holds the recorded execution log. The
> sections usually present in a core file capture the state of the
> inferior before the recording started, so that the file produced by
> this command can be used to replay the entire recorded session
> without the need to restore the initial state by some other means.
>
>
Great. Thanks a lot.
I make a new doc patch according to it.
Hui
2009-08-31 Hui Zhu <teawater@gmail.com>
* gdb.texinfo (Process Record and Replay): Document the
"record dump" commands.
---
doc/gdb.texinfo | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
--- a/doc/gdb.texinfo
+++ b/doc/gdb.texinfo
@@ -5214,6 +5214,22 @@ When record target runs in replay mode (
subsequent execution log and begin to record a new execution log starting
from the current address. This means you will abandon the previously
recorded ``future'' and begin recording a new ``future''.
+
+@kindex record dump
+@kindex rec dump
+@item record dump [@var{file}]
+@itemx rec dump [@var{file}]
+Dump the execution records of the inferior process to the named
+@var{file}. If not specified, @var{file} defaults to
+@file{gdb_record.@var{pid}}, where @var{pid} is is the PID of the
+inferior process.
+
+The file created by this command is actually a kind of core file,
+with an extra section that holds the recorded execution log. The
+sections usually present in a core file capture the state of the
+inferior before the recording started, so that the file produced by
+this command can be used to replay the entire recorded session
+without the need to restore the initial state by some other means.
@end table
next prev parent reply other threads:[~2009-08-31 2:52 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-01 7:31 Hui Zhu
2009-08-01 9:57 ` Eli Zaretskii
2009-08-01 19:20 ` Michael Snyder
2009-08-02 3:18 ` Michael Snyder
2009-08-02 5:58 ` Hui Zhu
2009-08-03 4:12 ` Hui Zhu
2009-08-03 18:29 ` Eli Zaretskii
2009-08-04 1:58 ` Hui Zhu
2009-08-04 2:07 ` Hui Zhu
2009-08-04 18:26 ` Eli Zaretskii
2009-08-04 20:01 ` Michael Snyder
2009-08-05 9:21 ` Hui Zhu
2009-08-05 20:19 ` [RFA/RFC] Add dump and load command to process record (file format etc) Michael Snyder
2009-08-06 2:17 ` Hui Zhu
2009-08-12 14:11 ` Michael Snyder
2009-08-12 15:16 ` Tom Tromey
2009-08-12 22:38 ` Michael Snyder
2009-08-16 0:04 ` Hui Zhu
2009-08-05 21:23 ` [RFA/RFC] Add dump and load command to process record and replay Michael Snyder
2009-08-06 3:14 ` Eli Zaretskii
2009-08-06 14:16 ` Hui Zhu
2009-08-07 3:27 ` Michael Snyder
2009-08-07 3:29 ` Hui Zhu
2009-08-07 3:34 ` Michael Snyder
2009-08-07 4:06 ` Hui Zhu
2009-08-07 8:41 ` Eli Zaretskii
2009-08-07 9:53 ` Hui Zhu
2009-08-07 12:51 ` Eli Zaretskii
2009-08-07 16:22 ` Hui Zhu
2009-08-07 17:42 ` Michael Snyder
2009-08-08 13:28 ` Hui Zhu
2009-08-10 3:09 ` Michael Snyder
2009-08-22 17:39 ` Hui Zhu
2009-08-23 1:14 ` Hui Zhu
2009-08-23 23:43 ` Michael Snyder
2009-08-24 8:20 ` Hui Zhu
2009-08-24 18:32 ` Michael Snyder
2009-08-25 8:47 ` Hui Zhu
2009-08-26 1:40 ` Michael Snyder
2009-08-26 2:59 ` Michael Snyder
2009-08-29 15:53 ` Hui Zhu
2009-08-29 18:06 ` Eli Zaretskii
2009-08-29 18:28 ` Hui Zhu
2009-08-29 20:26 ` Eli Zaretskii
2009-08-29 20:39 ` Michael Snyder
2009-08-30 3:03 ` Eli Zaretskii
2009-08-30 5:36 ` Hui Zhu
2009-08-30 23:40 ` Eli Zaretskii
2009-08-31 7:10 ` Hui Zhu [this message]
2009-09-05 3:30 ` Michael Snyder
2009-09-06 16:29 ` Hui Zhu
2009-08-29 20:05 ` Michael Snyder
2009-08-29 20:33 ` Eli Zaretskii
2009-08-29 21:20 ` Michael Snyder
2022-01-21 6:46 Simon Sobisch via Gdb-patches
2022-01-24 9:26 ` Hui Zhu via Gdb-patches
2022-04-13 12:21 ` Simon Sobisch via Gdb-patches
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=daef60380908301951m392aca0jccf3283f124066dd@mail.gmail.com \
--to=teawater@gmail.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=msnyder@vmware.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox