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

[Michael Snyder <msnyder@vmware.com>]

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
>