From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5681 invoked by alias); 5 Sep 2009 03:30:44 -0000 Received: (qmail 5667 invoked by uid 22791); 5 Sep 2009 03:30:43 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_37 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 05 Sep 2009 03:30:39 +0000 Received: from jupiter.vmware.com (mailhost5.vmware.com [10.16.68.131]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 5B6E41A001; Fri, 4 Sep 2009 20:30:37 -0700 (PDT) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by jupiter.vmware.com (Postfix) with ESMTP id 50E98DC07D; Fri, 4 Sep 2009 20:30:37 -0700 (PDT) Message-ID: <4AA1DB2A.1020701@vmware.com> Date: Sat, 05 Sep 2009 03:30:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Hui Zhu CC: Eli Zaretskii , "gdb-patches@sourceware.org" Subject: Re: [RFA/RFC] Add dump and load command to process record and replay References: <4A949176.9060604@vmware.com> <831vmubitq.fsf@gnu.org> <83zl9i9xls.fsf@gnu.org> <4A99909E.7030302@vmware.com> <83ws4m9fhr.fsf@gnu.org> <83skf99ob0.fsf@gnu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00112.txt.bz2 Hui Zhu wrote: > On Mon, Aug 31, 2009 at 01:58, Eli Zaretskii wrote: >>> From: Hui Zhu >>> Date: Sun, 30 Aug 2009 11:20:32 +0800 >>> Cc: Michael Snyder , 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 > > * 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 " which will do the necessary, by first invoking "core ", and then "target record". > @end table >