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
next prev 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).