Re: [PREC/RFA] Add not_replay to make precord support release memory better

[Michael Snyder <msnyder at vmware dot com>]

Hui Zhu wrote:
> On Fri, Jul 24, 2009 at 10:10, Michael Snyder<msnyder@vmware.com> 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.