From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9020 invoked by alias); 29 Aug 2009 18:28:52 -0000 Received: (qmail 9011 invoked by uid 22791); 29 Aug 2009 18:28:52 -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-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 29 Aug 2009 18:28:47 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id C8E6156007; Sat, 29 Aug 2009 11:28:44 -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 952BD8E7C3; Sat, 29 Aug 2009 11:28:44 -0700 (PDT) Message-ID: <4A997370.9020504@vmware.com> Date: Sat, 29 Aug 2009 20:05:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Eli Zaretskii CC: Hui Zhu , "gdb-patches@sourceware.org" Subject: Re: [RFA/RFC] Add dump and load command to process record and replay References: <4A7F5410.4000400@vmware.com> <4A91CEEC.5000802@vmware.com> <4A92D317.9010002@vmware.com> <4A948FF1.6000405@vmware.com> <4A949176.9060604@vmware.com> <831vmubitq.fsf@gnu.org> In-Reply-To: <831vmubitq.fsf@gnu.org> 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-08/txt/msg00544.txt.bz2 Eli Zaretskii wrote: >> From: Hui Zhu >> Date: Sat, 29 Aug 2009 23:18:29 +0800 >> Cc: Eli Zaretskii , "gdb-patches@sourceware.org" >> >> +@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 a core file. > > "A core file"? you didn't really mean that, did you? Yep! That was my suggestion. We use a core file to capture the state at the beginning of the recording, then add an extra bfd section to the corefile and write the recording log into that.