public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@palves.net>
To: Tom Tromey <tom@tromey.com>
Cc: Andrew Burgess <aburgess@redhat.com>,
	gdb-patches@sourceware.org, Matt Turner <mattst88@gmail.com>
Subject: Re: [PATCH] Linux: Avoid pread64/pwrite64 for high memory addresses (PR gdb/30525)
Date: Thu, 6 Jul 2023 18:00:27 +0100	[thread overview]
Message-ID: <17a52bbc-1bed-0850-1096-4a502fc52b86@palves.net> (raw)
In-Reply-To: <c798e514-0670-9630-3516-5e304521eece@palves.net>

On 2023-07-06 17:47, Pedro Alves wrote:

> From what I can tell in those two threads, this was really only about the comments case.  I'll
> drop the braces from my patch and merge it.

Done, like so.  Just realized I forgot to add Andrew's tag.  Sorry about that...

From 31a56a22c45d76df4c597439f337e3f75ac3065c Mon Sep 17 00:00:00 2001
From: Pedro Alves <pedro@palves.net>
Date: Wed, 7 Jun 2023 10:38:14 +0100
Subject: [PATCH] Linux: Avoid pread64/pwrite64 for high memory addresses (PR
 gdb/30525)

Since commit 05c06f318fd9 ("Linux: Access memory even if threads are
running"), GDB prefers pread64/pwrite64 to access inferior memory
instead of ptrace.  That change broke reading shared libraries on
SPARC64 Linux, as reported by PR gdb/30525 ("gdb cannot read shared
libraries on SPARC64").

On SPARC64 Linux, surprisingly (to me), userspace shared libraries are
mapped at high 64-bit addresses:

   (gdb) info sharedlibrary
   Cannot access memory at address 0xfff80001002011e0
   Cannot access memory at address 0xfff80001002011d8
   Cannot access memory at address 0xfff80001002011d8
   From                To                  Syms Read   Shared Object Library
   0xfff80001000010a0  0xfff8000100021f80  Yes (*)     /lib64/ld-linux.so.2
   (*): Shared library is missing debugging information.

Those addresses are 64-bit addresses with the high bits set.  When
interpreted as signed, they're negative.

The Linux kernel rejects pread64/pwrite64 if the offset argument of
type off_t (a signed type) is negative, which happens if the memory
address we're accessing has its high bit set.  See
linux/fs/read_write.c sys_pread64 and sys_pwrite64 in Linux.

Thankfully, lseek does not fail in that situation.  So the fix is to
use the 'lseek + read|write' path if the offset would be negative.

Fix this in both native GDB and GDBserver.

Tested on a SPARC64 GNU/Linux and x86-64 GNU/Linux.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30525
Change-Id: I79c724f918037ea67b7396fadb521bc9d1b10dc5
---
 gdb/linux-nat.c        | 28 ++++++++++++++++++----------
 gdbserver/linux-low.cc | 29 +++++++++++++++++------------
 2 files changed, 35 insertions(+), 22 deletions(-)

diff --git a/gdb/linux-nat.c b/gdb/linux-nat.c
index 383ef58fa23..4f7b6f8194f 100644
--- a/gdb/linux-nat.c
+++ b/gdb/linux-nat.c
@@ -3909,18 +3909,26 @@ linux_proc_xfer_memory_partial_fd (int fd, int pid,
 
   gdb_assert (fd != -1);
 
-  /* 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).  */
+  /* 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).  But only use them if the
+     offset isn't so high that when cast to off_t it'd be negative, as
+     seen on SPARC64.  pread64/pwrite64 outright reject such offsets.
+     lseek does not.  */
 #ifdef HAVE_PREAD64
-  ret = (readbuf ? pread64 (fd, readbuf, len, offset)
-	 : pwrite64 (fd, writebuf, len, offset));
-#else
-  ret = lseek (fd, offset, SEEK_SET);
-  if (ret != -1)
-    ret = (readbuf ? read (fd, readbuf, len)
-	   : write (fd, writebuf, len));
+  if ((off_t) offset >= 0)
+    ret = (readbuf != nullptr
+	   ? pread64 (fd, readbuf, len, offset)
+	   : pwrite64 (fd, writebuf, len, offset));
+  else
 #endif
+    {
+      ret = lseek (fd, offset, SEEK_SET);
+      if (ret != -1)
+	ret = (readbuf != nullptr
+	       ? read (fd, readbuf, len)
+	       : write (fd, writebuf, len));
+    }
 
   if (ret == -1)
     {
diff --git a/gdbserver/linux-low.cc b/gdbserver/linux-low.cc
index 8ab16698632..651f219b738 100644
--- a/gdbserver/linux-low.cc
+++ b/gdbserver/linux-low.cc
@@ -5377,21 +5377,26 @@ proc_xfer_memory (CORE_ADDR memaddr, unsigned char *readbuf,
     {
       int bytes;
 
-      /* 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).  But only
+	 use them if the offset isn't so high that when cast to off_t
+	 it'd be negative, as seen on SPARC64.  pread64/pwrite64
+	 outright reject such offsets.  lseek does not.  */
 #ifdef HAVE_PREAD64
-      bytes = (readbuf != nullptr
-	       ? pread64 (fd, readbuf, len, memaddr)
-	       : pwrite64 (fd, writebuf, len, memaddr));
-#else
-      bytes = -1;
-      if (lseek (fd, memaddr, SEEK_SET) != -1)
+      if ((off_t) memaddr >= 0)
 	bytes = (readbuf != nullptr
-		 ? read (fd, readbuf, len)
-		 : write (fd, writebuf, len));
+		 ? pread64 (fd, readbuf, len, memaddr)
+		 : pwrite64 (fd, writebuf, len, memaddr));
+      else
 #endif
+	{
+	  bytes = -1;
+	  if (lseek (fd, memaddr, SEEK_SET) != -1)
+	    bytes = (readbuf != nullptr
+		     ? read (fd, readbuf, len)
+		     : write (fd, writebuf, len));
+	}
 
       if (bytes < 0)
 	return errno;

base-commit: c0c3bb70f2f13e07295041cdf24a4d2997fe99a4
-- 
2.34.1


  reply	other threads:[~2023-07-06 17:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-05 13:41 Pedro Alves
2023-07-05 14:45 ` Matt Turner
2023-07-05 17:59 ` Andrew Burgess
2023-07-06 13:43   ` Pedro Alves
2023-07-06 13:54     ` Pedro Alves
2023-07-06 15:25       ` Tom Tromey
2023-07-06 16:47         ` Pedro Alves
2023-07-06 17:00           ` Pedro Alves [this message]
2023-07-07 15:18           ` Tom Tromey

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=17a52bbc-1bed-0850-1096-4a502fc52b86@palves.net \
    --to=pedro@palves.net \
    --cc=aburgess@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=mattst88@gmail.com \
    --cc=tom@tromey.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).