From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22265 invoked by alias); 29 Aug 2009 20:39:31 -0000 Received: (qmail 22257 invoked by uid 22791); 29 Aug 2009 20:39:31 -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, 29 Aug 2009 20:39:26 +0000 Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 3CD421A00C; Sat, 29 Aug 2009 13:39:25 -0700 (PDT) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by mailhost3.vmware.com (Postfix) with ESMTP id 34F08CD911; Sat, 29 Aug 2009 13:39:25 -0700 (PDT) Message-ID: <4A99920F.9040905@vmware.com> Date: Sat, 29 Aug 2009 21:20:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Eli Zaretskii CC: "teawater@gmail.com" , "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> <4A997370.9020504@vmware.com> <83y6p29xjp.fsf@gnu.org> In-Reply-To: <83y6p29xjp.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/msg00549.txt.bz2 Eli Zaretskii wrote: >> Date: Sat, 29 Aug 2009 11:29:04 -0700 >> From: Michael Snyder >> CC: Hui Zhu , >> "gdb-patches@sourceware.org" >> >>> "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. > > What is this useful for? I'm replying twice, just in case one of my explanations happens to 'click' better than the other. The record-log that process-record keeps in memory records only changes in state -- it does not contain a 'snapshot' of the entire state at any point (eg. at the beginning of the session). Therefore you can't use it unles you can first duplicate the starting state. Hui's approach was to first save a corefile, to record the starting state, and then save the changes file separately. A brilliant idea, but it has a drawback -- since they are separate files, there is no way to protect users against loading a start state from one program and a change set from a completely different program.