From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29093 invoked by alias); 25 Jul 2009 20:48:32 -0000 Received: (qmail 29084 invoked by uid 22791); 25 Jul 2009 20:48:32 -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, 25 Jul 2009 20:48:26 +0000 Received: from mailhost4.vmware.com (mailhost4.vmware.com [10.16.67.124]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id AEC913100B; Sat, 25 Jul 2009 13:48:24 -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 A71BBC9C81; Sat, 25 Jul 2009 13:48:24 -0700 (PDT) Message-ID: <4A6B6E02.5080702@vmware.com> Date: Sat, 25 Jul 2009 20:56:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Hui Zhu CC: gdb-patches ml Subject: Re: [PREC/RFA] Add not_replay to make precord support release memory better References: <4A69182D.9090004@vmware.com> In-Reply-To: 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-07/txt/msg00628.txt.bz2 Hui Zhu wrote: > On Fri, Jul 24, 2009 at 10:10, Michael Snyder wrote: >> 1) During the recording "pass", there's no change. >> 2) During the reverse-replay pass, if the memory is >> not readable or writable, we will set this flag to TRUE. >> 3) Finally, during the forward-replay pass, if the flag >> has previously been set to TRUE, we will skip this entry >> (and set the flag to FALSE.) >> >> So my question is -- is there any reason to set it to FALSE here? >> Is there any way that the memory can ever become readable again? >> >> Seems to me, once it is set TRUE, we might as well just leave it TRUE. >> Am I right? > > I thought about it too. I think if we don't need this entry. We can > delete it directly. > But there is a special status, after release memory, inferior alloc > some memory and its address is same with the memory that released > memory. Then the memory entry will can be use in this status. User > can get the right value of memory before this entry. So I think maybe > we can keep it. > > What do you think about it? Let's say a program does something like this: buf = mmap (...); munmap (...); buf = mmap (...); munmap (...); buf = mmap (...); and so on. And suppose that, for whatever reason, mmap always returns the same address. Then it seems to me (and please correct me if I am wrong), that it all depends on where we stop the recording. If we stop the recording after mmap, but before munmap, then the memory will be readable throughout the ENTIRE recording. But if we stop the recording after munmap, but before mmap, then the memory will NOT be readable (again for the entire recording). So as you replay backward and forward through the recording, the readability state of the memory location will never change -- it will remain either readable, or unreadable, depending only on the mapped-state when the recording ended. The only way for it to change, I think, would be if we could resume the process and add some more execution to the end of the existing recording.