public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Andreas Arnez <arnez@linux.vnet.ibm.com>
To: gdb-patches@sourceware.org
Subject: [PATCH 3/3] linux-nat: Exploit /proc/<pid>/mem for writing
Date: Mon, 06 Mar 2017 16:03:00 -0000	[thread overview]
Message-ID: <1488816060-20776-4-git-send-email-arnez@linux.vnet.ibm.com> (raw)
In-Reply-To: <1488816060-20776-1-git-send-email-arnez@linux.vnet.ibm.com>

So far linux_proc_xfer_partial refused to handle write requests.  This is
still based on the assumption that the Linux kernel does not support
writes to /proc/<pid>/mem.  That used to be true, but has changed with
Linux 2.6.39 released in May 2011.

This patch lifts this restriction and now exploits /proc/<pid>/mem for
writing to inferior memory as well, if possible.

gdb/ChangeLog:

	* linux-nat.c (linux_proc_xfer_partial): Handle write operations
	as well.
---
 gdb/linux-nat.c | 32 ++++++++++++++++----------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/gdb/linux-nat.c b/gdb/linux-nat.c
index c58ed83..73ef2d4 100644
--- a/gdb/linux-nat.c
+++ b/gdb/linux-nat.c
@@ -3978,10 +3978,9 @@ linux_child_pid_to_exec_file (struct target_ops *self, int pid)
   return linux_proc_pid_to_exec_file (pid);
 }
 
-/* Implement the to_xfer_partial interface for memory reads using the /proc
-   filesystem.  Because we can use a single read() call for /proc, this
-   can be much more efficient than banging away at PTRACE_PEEKTEXT,
-   but it doesn't support writes.  */
+/* Implement the to_xfer_partial target method using /proc/<pid>/mem.
+   Because we can use a single read/write call, this can be much more
+   efficient than banging away at PTRACE_PEEKTEXT.  */
 
 static enum target_xfer_status
 linux_proc_xfer_partial (struct target_ops *ops, enum target_object object,
@@ -3993,7 +3992,7 @@ linux_proc_xfer_partial (struct target_ops *ops, enum target_object object,
   int fd;
   char filename[64];
 
-  if (object != TARGET_OBJECT_MEMORY || !readbuf)
+  if (object != TARGET_OBJECT_MEMORY)
     return TARGET_XFER_EOF;
 
   /* Don't bother for one word.  */
@@ -4004,26 +4003,27 @@ linux_proc_xfer_partial (struct target_ops *ops, enum target_object object,
      thread.  That requires some juggling, but is even faster.  */
   xsnprintf (filename, sizeof filename, "/proc/%d/mem",
 	     ptid_get_pid (inferior_ptid));
-  fd = gdb_open_cloexec (filename, O_RDONLY | O_LARGEFILE, 0);
+  fd = gdb_open_cloexec (filename, ((readbuf ? O_RDONLY : O_WRONLY)
+				    | O_LARGEFILE), 0);
   if (fd == -1)
     return TARGET_XFER_EOF;
 
-  /* If pread64 is available, use it.  It's faster if the kernel
-     supports it (only one syscall), and it's 64-bit safe even on
-     32-bit platforms (for instance, SPARC debugging a SPARC64
-     application).  */
+  /* Use pread64/pwrite64 if available, since they save a syscall and can
+     handle 64-bit offsets even on 32-bit platforms (for instance, SPARC
+     debugging a SPARC64 application).  */
 #ifdef HAVE_PREAD64
-  if (pread64 (fd, readbuf, len, offset) != len)
+  ret = (readbuf ? pread64 (fd, readbuf, len, offset)
+	 : pwrite64 (fd, writebuf, len, offset));
 #else
-  if (lseek (fd, offset, SEEK_SET) == -1 || read (fd, readbuf, len) != len)
+  ret = lseek (fd, offset, SEEK_SET);
+  if (ret != -1)
+    ret = (readbuf ? read (fd, readbuf, len)
+	   : write (fd, writebuf, len));
 #endif
-    ret = 0;
-  else
-    ret = len;
 
   close (fd);
 
-  if (ret == 0)
+  if (ret == -1 || ret == 0)
     return TARGET_XFER_EOF;
   else
     {
-- 
2.3.0

  parent reply	other threads:[~2017-03-06 16:03 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-06 16:01 [PATCH 0/3] PR gdb/21220: Fix quadratic runtime of memory writes into inferior on GNU/Linux Andreas Arnez
2017-03-06 16:01 ` [PATCH 1/3] inf-ptrace: Do not stop memory transfers after a single word Andreas Arnez
2017-03-08 19:10   ` Simon Marchi
2017-03-09 17:22     ` Andreas Arnez
2017-03-10 15:49       ` Simon Marchi
2017-03-13 19:39         ` Pedro Alves
2017-03-13 19:50           ` Andreas Arnez
2017-03-13 19:51             ` Pedro Alves
2017-03-14 15:12               ` Andreas Arnez
2017-03-14 15:23                 ` Pedro Alves
2017-03-06 16:02 ` [PATCH 2/3] Test case for dump/restore of large array Andreas Arnez
2017-03-13 19:51   ` Pedro Alves
2017-03-06 16:03 ` Andreas Arnez [this message]
2017-03-13 20:05   ` [PATCH 3/3] linux-nat: Exploit /proc/<pid>/mem for writing Pedro Alves
2017-03-13 20:08     ` Pedro Alves
2017-03-14 11:23       ` Andreas Arnez
2017-03-14  9:54     ` Andreas Arnez

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=1488816060-20776-4-git-send-email-arnez@linux.vnet.ibm.com \
    --to=arnez@linux.vnet.ibm.com \
    --cc=gdb-patches@sourceware.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).