This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA/RFC] Add dump and load command to process record and replay
- From: Hui Zhu <teawater at gmail dot com>
- To: Michael Snyder <msnyder at vmware dot com>
- Cc: Eli Zaretskii <eliz at gnu dot org>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Mon, 7 Sep 2009 00:28:29 +0800
- Subject: Re: [RFA/RFC] Add dump and load command to process record and replay
- References: <daef60380908010030o1189baaal3927a286e069971c@mail.gmail.com> <831vmubitq.fsf@gnu.org> <daef60380908291105v1cc58833vea406b2de0b37f20@mail.gmail.com> <83zl9i9xls.fsf@gnu.org> <4A99909E.7030302@vmware.com> <83ws4m9fhr.fsf@gnu.org> <daef60380908292020q4cf7b2a0he2a0f15f226175a0@mail.gmail.com> <83skf99ob0.fsf@gnu.org> <daef60380908301951m392aca0jccf3283f124066dd@mail.gmail.com> <4AA1DB2A.1020701@vmware.com>
On Sat, Sep 5, 2009 at 11:29, Michael Snyder<msnyder@vmware.com> wrote:
> Hui Zhu wrote:
>>
>> 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.
>
> Since there is no "record load" command in this version, perhaps
> we should say something here about how to reload the file?
>
> Something like:
>
> To reload the execution record file, first open it like an
> ordinary core file, then use "target record".
>
> Alternatively, maybe you want to add a new version of
> "record load <filename>" which will do the necessary,
> by first invoking "core <filename>", and then "target
> record".
>
>
>> ?@end table
>>
>
>
I am not sure which way is better. Could you help me with it?
Thanks,
Hui