From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24795 invoked by alias); 17 Oct 2009 22:25:50 -0000 Received: (qmail 24784 invoked by uid 22791); 17 Oct 2009 22:25:48 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 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, 17 Oct 2009 22:25:44 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 373312302F; Sat, 17 Oct 2009 15:25:43 -0700 (PDT) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by mailhost2.vmware.com (Postfix) with ESMTP id 1D7298E7EC; Sat, 17 Oct 2009 15:25:43 -0700 (PDT) Message-ID: <4ADA430C.9080502@vmware.com> Date: Sat, 17 Oct 2009 22:25:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Eli Zaretskii , "gdb-patches@sourceware.org" , Hui Zhu Subject: Re: [RFA, 4 of 3] save/restore process record, part 4 (docs and news) References: <4ADA1577.4000100@vmware.com> <83ljj9hj6n.fsf@gnu.org> In-Reply-To: <83ljj9hj6n.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------010803070408050205040901" 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-10/txt/msg00400.txt.bz2 This is a multi-part message in MIME format. --------------010803070408050205040901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1064 Eli Zaretskii wrote: >> Date: Sat, 17 Oct 2009 12:05:27 -0700 >> From: Michael Snyder >> >> The fourth part of the trilogy. ;-) > > Thanks. > >> * docs/gdb.texinfo: Document record save/restore commands. > > This needs to state the name of the node where you made the changes. OK >> +* New commands >> + >> +record save -- Save a 'process record' execution log to a file. >> +record restore > Please format these as we did with other new commands in NEWS. Well, there's more than one format -- I'll use the most recent. >> +Save the execution log of the inferior process into a modified core file. > > "Modified" is too overloaded. Suggest "specially formatted" instead. OK. >> +This execution log can then be debugged using the @code{process record} > > Well, you can't really "debug the execution log", can you? How about > > You can then replay this execution log as if you recorded it in this > @value{GDBN} session. All right. See attached. --------------010803070408050205040901 Content-Type: text/plain; name="docsb.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="docsb.txt" Content-length: 2209 2009-10-17 Hui Zhu Michael Snyder * docs/gdb.texinfo (Process Record and Replay): Document record save/restore commands. * NEWS: Mention record save/restore commands. Index: NEWS =================================================================== RCS file: /cvs/src/src/gdb/NEWS,v retrieving revision 1.334 diff -u -p -r1.334 NEWS --- NEWS 15 Oct 2009 19:28:52 -0000 1.334 +++ NEWS 17 Oct 2009 22:24:59 -0000 @@ -11,6 +11,13 @@ Xilinx MicroBlaze microblaze-*-* Xilinx MicroBlaze microblaze +* New commands + +record save (filename) + Save a 'process record' execution log to a file. +record restore (filename) + Restore an earlier 'process record' session. + *** Changes in GDB 7.0 * GDB now has an interface for JIT compilation. Applications that Index: doc/gdb.texinfo =================================================================== RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v retrieving revision 1.633 diff -u -p -r1.633 gdb.texinfo --- doc/gdb.texinfo 12 Oct 2009 01:59:54 -0000 1.633 +++ doc/gdb.texinfo 17 Oct 2009 22:24:59 -0000 @@ -5348,6 +5348,26 @@ 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 save +@kindex rec save +@item record save [@var{file}] +@itemx rec save [@var{file}] +Save the execution log of the inferior process into a modified core file. +The optional argument @var{file} specifies the file name in which to +save the execution log. If not specified, the file name defaults +to @file{gdb_record.@var{pid}}, where @var{pid} is is the PID of the +inferior process. + +@kindex record restore +@kindex rec restore +@item record restore [@var{file}] +@itemx rec restore [@var{file}] +Restore the execution log of an earlier session from the file @var{file} +(required), which has been created using the command @code{record save}. +This execution log can then be debugged using the @code{process record} +target, in replay mode, just like replaying a live debugging session. + @end table --------------010803070408050205040901--