From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1440 invoked by alias); 7 Aug 2009 17:22:01 -0000 Received: (qmail 1428 invoked by uid 22791); 7 Aug 2009 17:21:59 -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; Fri, 07 Aug 2009 17:21:52 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 3158731003; Fri, 7 Aug 2009 10:21:49 -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 117458E5B6; Fri, 7 Aug 2009 10:21:49 -0700 (PDT) Message-ID: <4A7C625B.8080005@vmware.com> Date: Fri, 07 Aug 2009 17:42: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: <83my6fo2pa.fsf@gnu.org> <4A78935B.5030508@vmware.com> <4A79F802.4060102@vmware.com> <83ab2docqi.fsf@gnu.org> <4A7B99B3.40407@vmware.com> <4A7B9F49.9030202@vmware.com> <83ws5gm30b.fsf@gnu.org> In-Reply-To: <83ws5gm30b.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/msg00113.txt.bz2 Eli Zaretskii wrote: >> From: Hui Zhu >> Date: Fri, 7 Aug 2009 11:34:20 +0800 >> Cc: Eli Zaretskii , "gdb-patches@sourceware.org" >> >> I think a warning is clear to most of people. >> >> And when he get this warning. He can delete the record list and load >> again. He will lost nothing. >> >> If we delete the old record list, maybe he still need old record. He >> will lost something. > > Instead of a warning, how about asking the user whether to discard the > old records or keep them? My concern is, in most cases keeping them will be the wrong thing to do. It will be very easy to create an internally inconsistent state, and rather unlikely to create one that is *not* internally inconsistant. Think about it -- we will be concatenating two independent sets of state changes, with no way of knowing that the actual machine state at the end of one is the same as the machine state at the beginning of the other. When these are then replayed, their effect may have little or nothing to do with what the real machine would actually do. To actually get this right, you would have to be *sure* that your target machine is in the exact same state "now" (ie. when you do the load command) as it was at the *beginning* of the previous recording/debugging session. I would rather either make this a separate, "expert mode" command, or better still, leave it for a future patch to extend the basic (and safe) patch that we first accept.