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

[Hui Zhu <teawater@gmail.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