Re: [RFA/RFC] Add dump and load command to process record and replay

[Hui Zhu <teawater at gmail dot 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