From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21226 invoked by alias); 29 Aug 2009 20:33:25 -0000 Received: (qmail 21217 invoked by uid 22791); 29 Aug 2009 20:33:24 -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 20:33:19 +0000 Received: from mailhost4.vmware.com (mailhost4.vmware.com [10.16.67.124]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 84F4A13420; Sat, 29 Aug 2009 13:33:15 -0700 (PDT) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by mailhost4.vmware.com (Postfix) with ESMTP id 7C535C9A1B; Sat, 29 Aug 2009 13:33:15 -0700 (PDT) Message-ID: <4A99909E.7030302@vmware.com> Date: Sat, 29 Aug 2009 20:39: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: <4A91CEEC.5000802@vmware.com> <4A92D317.9010002@vmware.com> <4A948FF1.6000405@vmware.com> <4A949176.9060604@vmware.com> <831vmubitq.fsf@gnu.org> <83zl9i9xls.fsf@gnu.org> In-Reply-To: <83zl9i9xls.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/msg00548.txt.bz2 Eli Zaretskii wrote: >> From: Hui Zhu >> Date: Sun, 30 Aug 2009 02:05:37 +0800 >> Cc: msnyder@vmware.com, gdb-patches@sourceware.org >> >>> "A core file"? you didn't really mean that, did you? >> Yes, it really dump record log to a core file. Now, record log is >> together with core file. > > Sorry, I don't understand: why would we want to have the record log in > a core file? What am I missing here? Because the record-log itself does not record starting state -- only changes of state. It is useless by itself if you don't restore the starting state first. Hui's original patch used the "gcore" command to save the starting state, and "target core" to restore it. The problem that I found with that was that it created two independent files, core file and record-log file, and that there was no way to assure ourselves (or the user) that the two files corresponded to one another when they were re-loaded. That's why I suggested combining them into one file -- in this implementation, by adding the record-log to an extra section in the core file.