From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14928 invoked by alias); 27 Jul 2009 16:08:09 -0000 Received: (qmail 14917 invoked by uid 22791); 27 Jul 2009 16:08:07 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-pz0-f203.google.com (HELO mail-pz0-f203.google.com) (209.85.222.203) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 27 Jul 2009 16:07:58 +0000 Received: by pzk41 with SMTP id 41so2313283pzk.12 for ; Mon, 27 Jul 2009 09:07:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.97.20 with SMTP id u20mr1013993wfb.14.1248710877078; Mon, 27 Jul 2009 09:07:57 -0700 (PDT) In-Reply-To: <4A6B6E02.5080702@vmware.com> References: <4A69182D.9090004@vmware.com> <4A6B6E02.5080702@vmware.com> From: Hui Zhu Date: Mon, 27 Jul 2009 16:18:00 -0000 Message-ID: Subject: Re: [PREC/RFA] Add not_replay to make precord support release memory better To: Michael Snyder Cc: gdb-patches ml Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00649.txt.bz2 On Sun, Jul 26, 2009 at 04:41, Michael Snyder wrote: > 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. =A0I think if we don't need this entry. =A0We 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. =A0Then the memory entry will can be use in this status. =A0User >> can get the right value of memory before this entry. =A0So I think maybe >> we can keep it. >> >> What do you think about it? > > Let's say a program does something like this: > > buf =3D mmap (...); > munmap (...); > buf =3D mmap (...); > munmap (...); > buf =3D mmap (...); > > and so on. =A0And 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. > Agree with you. We can do more thing around release memory. But this patch make prec work OK even if inferior release some memory. Of course, the released memory we still can not access. But other memory is OK. This is a low cost idea for release memory. And we still can add other thing about release memory. Thanks, Hui