Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Michael Snyder <msnyder@vmware.com>
To: Hui Zhu <teawater@gmail.com>
Cc: gdb-patches ml <gdb-patches@sourceware.org>
Subject: Re: [PREC/RFA] Add not_replay to make precord support release memory  	better
Date: Sat, 01 Aug 2009 23:01:00 -0000	[thread overview]
Message-ID: <4A74C90D.4040004@vmware.com> (raw)
In-Reply-To: <daef60380907270907h617cf560k2795a66a35baba9c@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3269 bytes --]

Hui Zhu wrote:
> On Sun, Jul 26, 2009 at 04:41, Michael Snyder<msnyder@vmware.com> wrote:
>> 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.
>>
> 
> 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.

Yes, I like the patch, and I want to see it go in, but
you haven't really answered my question:

Once we have set this flag to TRUE in a recording entry,
why would we ever need to set it to FALSE?

The patch is simpler and easier to understand if we simply
leave the flag TRUE.  It worries me to see it toggling back
and forth between TRUE and FALSE every time we play through
the recording, if there is no benefit to doing that.  Plus
it means that we keep trying to read the target memory even
though we know it will fail.

I'm attaching a diff to show what I mean, in case it isn't clear.
This diff gives me the same behavior with your munmap test case
as your diff does.




[-- Attachment #2: memaccess.txt --]
[-- Type: text/plain, Size: 3385 bytes --]

Index: record.c
===================================================================
RCS file: /cvs/src/src/gdb/record.c,v
retrieving revision 1.9
diff -u -p -r1.9 record.c
--- record.c	22 Jul 2009 05:31:26 -0000	1.9
+++ record.c	1 Aug 2009 22:59:55 -0000
@@ -51,6 +51,7 @@ struct record_mem_entry
 {
   CORE_ADDR addr;
   int len;
+  int mem_entry_not_accessible;
   gdb_byte *val;
 };
 
@@ -275,6 +276,7 @@ record_arch_list_add_mem (CORE_ADDR addr
   rec->type = record_mem;
   rec->u.mem.addr = addr;
   rec->u.mem.len = len;
+  rec->u.mem.mem_entry_not_accessible = 0;
 
   if (target_read_memory (addr, rec->u.mem.val, len))
     {
@@ -727,32 +729,52 @@ record_wait (struct target_ops *ops,
 	  else if (record_list->type == record_mem)
 	    {
 	      /* mem */
-	      gdb_byte *mem = alloca (record_list->u.mem.len);
-	      if (record_debug > 1)
-		fprintf_unfiltered (gdb_stdlog,
-				    "Process record: record_mem %s to "
-				    "inferior addr = %s len = %d.\n",
-				    host_address_to_string (record_list),
-				    paddress (gdbarch, record_list->u.mem.addr),
-				    record_list->u.mem.len);
-
-	      if (target_read_memory
-		  (record_list->u.mem.addr, mem, record_list->u.mem.len))
-		error (_("Process record: error reading memory at "
-			 "addr = %s len = %d."),
-		       paddress (gdbarch, record_list->u.mem.addr),
-		       record_list->u.mem.len);
-
-	      if (target_write_memory
-		  (record_list->u.mem.addr, record_list->u.mem.val,
-		   record_list->u.mem.len))
-		error (_
-		       ("Process record: error writing memory at "
-			"addr = %s len = %d."),
-		       paddress (gdbarch, record_list->u.mem.addr),
-		       record_list->u.mem.len);
-
-	      memcpy (record_list->u.mem.val, mem, record_list->u.mem.len);
+	      if (record_list->u.mem.mem_entry_not_accessible == 0)
+		{
+		  gdb_byte *mem = alloca (record_list->u.mem.len);
+		  if (record_debug > 1)
+		    fprintf_unfiltered (gdb_stdlog,
+				        "Process record: record_mem %s to "
+				        "inferior addr = %s len = %d.\n",
+				        host_address_to_string (record_list),
+				        paddress (gdbarch,
+					          record_list->u.mem.addr),
+				        record_list->u.mem.len);
+
+		  if (target_read_memory (record_list->u.mem.addr, mem,
+		                          record_list->u.mem.len))
+	            {
+		      if (execution_direction != EXEC_REVERSE)
+		        error (_("Process record: error reading memory at "
+			         "addr = %s len = %d."),
+		               paddress (gdbarch, record_list->u.mem.addr),
+		               record_list->u.mem.len);
+		      else
+		        record_list->u.mem.mem_entry_not_accessible = 1;
+		    }
+		  else
+		    {
+		      if (target_write_memory (record_list->u.mem.addr,
+			                       record_list->u.mem.val,
+		                               record_list->u.mem.len))
+	                {
+			  if (execution_direction != EXEC_REVERSE)
+			    error (_("Process record: error writing memory at "
+			             "addr = %s len = %d."),
+		                   paddress (gdbarch, record_list->u.mem.addr),
+		                   record_list->u.mem.len);
+			  else
+			    {
+			      record_list->u.mem.mem_entry_not_accessible = 1;
+			    }
+			}
+		      else
+		        {
+			  memcpy (record_list->u.mem.val, mem,
+				  record_list->u.mem.len);
+			}
+		    }
+		}
 	    }
 	  else
 	    {

  reply	other threads:[~2009-08-01 23:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-21 15:39 Hui Zhu
2009-07-24 11:31 ` Michael Snyder
2009-07-24 13:00   ` Hui Zhu
2009-07-25 20:56     ` Michael Snyder
2009-07-27 16:18       ` Hui Zhu
2009-08-01 23:01         ` Michael Snyder [this message]
2009-08-02  4:11           ` Hui Zhu
2009-08-03  3:51             ` Hui Zhu
2009-08-03  5:02               ` Michael Snyder
2009-08-03  5:19                 ` Hui Zhu
2009-08-03 17:31                   ` Michael Snyder
2009-08-04  1:50                     ` Hui Zhu
2009-08-04 18:19                       ` Michael Snyder
2009-08-05  1:26                         ` Hui Zhu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A74C90D.4040004@vmware.com \
    --to=msnyder@vmware.com \
    --cc=gdb-patches@sourceware.org \
    --cc=teawater@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox