[Bug gdb/30525] New: gdb cannot read shared libraries on SPARC64

[Bug gdb/30525] New: gdb cannot read shared libraries on SPARC64

[mattst88 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30525

            Bug ID: 30525
           Summary: gdb cannot read shared libraries on SPARC64
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: mattst88 at gmail dot com
  Target Milestone: ---

Downstream bug: https://bugs.gentoo.org/907906

On sparc64 userland, gdb cannot read shared libraries:

(64-bit chroot) catbus ~ # cat t.c
#include <stdio.h>

int main(void) {
        printf("hello world\n");
        return 0;
}
(64-bit chroot) catbus ~ # gcc -g t.c -o t
(64-bit chroot) catbus ~ # gdb -q t
Reading symbols from t...
(gdb) start
Temporary breakpoint 1 at 0x7b8: file t.c, line 4.
Starting program: /root/t 

Temporary breakpoint 1, main () at t.c:4
4               printf("hello world\n");
(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.

As a result, breakpoints in shared libraries don't work.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30525] gdb cannot read shared libraries on SPARC64

[mattst88 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30525

Matt Turner <mattst88 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
               Host|                            |sparc64-unknown-linux-gnu

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30525] gdb cannot read shared libraries on SPARC64

[mattst88 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30525

Matt Turner <mattst88 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palves at sourceware dot org,
                   |                            |pedro at palves dot net

--- Comment #1 from Matt Turner <mattst88 at gmail dot com> ---
I've bisected this to commit 05c06f318fd9a112529dfc313e6512b399a645e4.

I bisected between gdb-10-branchpoint and gdb-11-branchpoint. Here's the bisect
log.

git bisect start
# status: waiting for both good and bad commits
# good: [8087c3fa8b5d695e3e29e69d70d0b35ec902ac59] Fix GDB build in infrun.c
when configured with unit tests disabled
git bisect good 8087c3fa8b5d695e3e29e69d70d0b35ec902ac59
# status: waiting for bad commit, 1 good commit known
# bad: [4b51505e33441c6165e7789fa2b6d21930242927] More minor updates to the
how-to-make-a-release documentation
git bisect bad 4b51505e33441c6165e7789fa2b6d21930242927
# good: [616c069a3f1a841e5bc63d20aec8e5b71b499f6c] gdb/dwarf: don't enqueue CU
in maybe_queue_comp_unit if already expanded
git bisect good 616c069a3f1a841e5bc63d20aec8e5b71b499f6c
# good: [ec098003e27d67bca9e9880320e26ab8ad30fe31] gdbsupport: introduce struct
observer
git bisect good ec098003e27d67bca9e9880320e26ab8ad30fe31
# good: [c445a939101ce78dfd62fdbd97906768aca2ed4d] Automatic date update in
version.in
git bisect good c445a939101ce78dfd62fdbd97906768aca2ed4d
# good: [7b2298cbd812320c7f78d41d556ecb174cfdd675] sim: mips: fix uninitialized
register use
git bisect good 7b2298cbd812320c7f78d41d556ecb174cfdd675
# good: [bf1dcdb3910e003c29c278ddb48eb56cfd045138] Consolidate CU language
setting
git bisect good bf1dcdb3910e003c29c278ddb48eb56cfd045138
# good: [4743af62eb6f00c385dccff54df43ae0bbf31cd3] gdb: remove duplicate
declaration of 'find_thread_ptid'
git bisect good 4743af62eb6f00c385dccff54df43ae0bbf31cd3
# good: [9cb74cfd815bfab451546206094b7ab49d382a24] Automatic date update in
version.in
git bisect good 9cb74cfd815bfab451546206094b7ab49d382a24
# bad: [d4a0121347ad9890060709a2a7660e0ac58b4b84] sim: m32r: replace custom
endian helpers with sim-endian
git bisect bad d4a0121347ad9890060709a2a7660e0ac58b4b84
# bad: [ac8ef6961e18664224b55c1eadc611f0e9f1e5b5] opcodes: constify & localize
z80 opcodes
git bisect bad ac8ef6961e18664224b55c1eadc611f0e9f1e5b5
# bad: [05c06f318fd9a112529dfc313e6512b399a645e4] Linux: Access memory even if
threads are running
git bisect bad 05c06f318fd9a112529dfc313e6512b399a645e4
# good: [75a2da57a1bbff8686f56a43aabe1d7e55147894] readelf: Reset file position
to beginning for thin archive members
git bisect good 75a2da57a1bbff8686f56a43aabe1d7e55147894
# first bad commit: [05c06f318fd9a112529dfc313e6512b399a645e4] Linux: Access
memory even if threads are running

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30525] gdb cannot read shared libraries on SPARC64

[sam at gentoo dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30525

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sam at gentoo dot org
           See Also|                            |https://bugs.gentoo.org/sho
                   |                            |w_bug.cgi?id=907906

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30525] gdb cannot read shared libraries on SPARC64

[sam at gentoo dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30525

--- Comment #2 from Sam James <sam at gentoo dot org> ---
We have a sparc box folks are free to have access to if needed, as well.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30525] gdb cannot read shared libraries on SPARC64

[pedro at palves dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=30525

--- Comment #3 from Pedro Alves <pedro at palves dot net> ---
> (gdb) info sharedlibrary
> Cannot access memory at address 0xfff80001002011e0
> Cannot access memory at address 0xfff80001002011d8
> Cannot access memory at address 0xfff80001002011d8

Those addresses look suspiciously high for userspace.  They are 64-bit
addresses, with the high bits set.  When interpreted as signed, they'd be
negative.  Are they really correct?

We have, in gdb/linux-nat.c:

static enum target_xfer_status
linux_proc_xfer_memory_partial_fd (int fd, int pid,
                                   gdb_byte *readbuf, const gdb_byte *writebuf,
                                   ULONGEST offset, LONGEST len,
                                   ULONGEST *xfered_len)
{
  ssize_t ret;

  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).  */
#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));
#endif


So one thing to check is whether the HAVE_PREAD64 code is enabled.  And then,
that may be failing due to a negative offset, give pread64's offset parameter
is an off_t.

Try enabling "set debug linux-nat 1", so that the following log is output:

  if (ret == -1)
    {
      linux_nat_debug_printf ("accessing fd %d for pid %d failed: %s (%d)",
                              fd, pid, safe_strerror (errno), errno);
      return TARGET_XFER_E_IO;
    }

Maybe the errno gives us some clue.

Does hacking the linux-nat.c:proc_mem_file_is_writable to always return false
paper over the problem?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30525] gdb cannot read shared libraries on SPARC64

[pedro at palves dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=30525

--- Comment #4 from Pedro Alves <pedro at palves dot net> ---
Created attachment 14921
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14921&action=edit
Avoid pread64/pwrite64 for high memory addresses

I wonder whether this patch fixes it.  Can you give it a try?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30525] gdb cannot read shared libraries on SPARC64

[pedro at palves dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=30525

Pedro Alves <pedro at palves dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #14921|0                           |1
        is obsolete|                            |

--- Comment #5 from Pedro Alves <pedro at palves dot net> ---
Created attachment 14922
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14922&action=edit
Avoid pread64/pwrite64 for high memory addresses (v2)

The numeric limits thing was there because I initially thought about
incrementally lseeking in a loop with positive offsets until the high address
was reached.  If we can do it in one lseek call only, then it isn't needed. 
This slightly updated patch thus gets rid of the numeric limits use.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30525] gdb cannot read shared libraries on SPARC64

[mattst88 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30525

--- Comment #6 from Matt Turner <mattst88 at gmail dot com> ---
(In reply to Pedro Alves from comment #3)
> > (gdb) info sharedlibrary
> > Cannot access memory at address 0xfff80001002011e0
> > Cannot access memory at address 0xfff80001002011d8
> > Cannot access memory at address 0xfff80001002011d8
> 
> Those addresses look suspiciously high for userspace.  They are 64-bit
> addresses, with the high bits set.  When interpreted as signed, they'd be
> negative.  Are they really correct?

Unsure, but with gdb from the commit prior to the bisection:

(64-bit chroot) catbus ~ # gdb -q t
Reading symbols from t...
(gdb) start
Temporary breakpoint 1 at 0x7b8: file t.c, line 4.
Starting program: /root/t 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Temporary breakpoint 1, main () at t.c:4
4               printf("hello world\n");
(gdb) info sharedlibrary
From                To                  Syms Read   Shared Object Library
0xfff80001000010a0  0xfff8000100021f80  Yes (*)     /lib64/ld-linux.so.2
0xfff800010032ae00  0xfff800010045ac80  Yes (*)     /lib64/libc.so.6
(*): Shared library is missing debugging information.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30525] gdb cannot read shared libraries on SPARC64

[mattst88 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30525

--- Comment #7 from Matt Turner <mattst88 at gmail dot com> ---
(In reply to Pedro Alves from comment #3)
> So one thing to check is whether the HAVE_PREAD64 code is enabled.  And
> then, that may be failing due to a negative offset, give pread64's offset
> parameter is an off_t.

pread64 is enabled:

checking for pread... yes
checking for pread64... yes
checking for pwrite... yes

config.h contains

/* Define to 1 if you have the `pread64' function. */
#define HAVE_PREAD64 1

> Try enabling "set debug linux-nat 1", so that the following log is output:
> 
>   if (ret == -1)
>     {
>       linux_nat_debug_printf ("accessing fd %d for pid %d failed: %s (%d)",
> 			      fd, pid, safe_strerror (errno), errno);
>       return TARGET_XFER_E_IO;
>     }
> 
> Maybe the errno gives us some clue.

[linux-nat] open_proc_mem_file: opened fd 14 for lwp 2314199.2314199
[linux-nat] linux_proc_xfer_memory_partial_fd: accessing fd 14 for pid 2314199
failed: Invalid argument (22)
[linux-nat] linux_proc_xfer_memory_partial_fd: accessing fd 14 for pid 2314199
failed: Invalid argument (22)

> Does hacking the linux-nat.c:proc_mem_file_is_writable to always return
> false paper over the problem?

Yes, it does.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30525] gdb cannot read shared libraries on SPARC64

[mattst88 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30525

--- Comment #8 from Matt Turner <mattst88 at gmail dot com> ---
(In reply to Pedro Alves from comment #5)
> Created attachment 14922 [details]
> Avoid pread64/pwrite64 for high memory addresses (v2)
> 
> The numeric limits thing was there because I initially thought about
> incrementally lseeking in a loop with positive offsets until the high
> address was reached.  If we can do it in one lseek call only, then it isn't
> needed.  This slightly updated patch thus gets rid of the numeric limits use.

This patch does not fix it.

Temporary breakpoint 1, main () at t.c:4
4               printf("hello world\n");
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30525] gdb cannot read shared libraries on SPARC64

[pedro at palves dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=30525

Pedro Alves <pedro at palves dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #14922|0                           |1
        is obsolete|                            |
           Assignee|unassigned at sourceware dot org   |pedro at palves dot net
   Last reconfirmed|                            |2023-06-07
             Status|UNCONFIRMED                 |ASSIGNED
     Ever confirmed|0                           |1

--- Comment #9 from Pedro Alves <pedro at palves dot net> ---
Created attachment 14925
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14925&action=edit
[PATCH] Avoid pread64/pwrite64 for high memory addresses

> This patch does not fix it.

Hmm, scary, but...

I meanwhile found a sparc64 linux box on the GCC compile farm and was able to
play with it.

And, err, it's just that I had the logic reversed in the patch...  :-P

The corrected version of the patch works for me, which is a big relief.

Could you give it a try too, just in case?

I'll see about running the whole GDB testsuite.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30525] gdb cannot read shared libraries on SPARC64

[pedro at palves dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=30525

Pedro Alves <pedro at palves dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #14925|[PATCH] Avoid               |[PATCH] Avoid
        description|pread64/pwrite64 for high   |pread64/pwrite64 for high
                   |memory addresses            |memory addresses (v3)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30525] gdb cannot read shared libraries on SPARC64

[mattst88 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30525

--- Comment #10 from Matt Turner <mattst88 at gmail dot com> ---
(In reply to Pedro Alves from comment #9)
> Created attachment 14925 [details]
> [PATCH] Avoid pread64/pwrite64 for high memory addresses (v3)
> 
> > This patch does not fix it.
> 
> Hmm, scary, but...
> 
> I meanwhile found a sparc64 linux box on the GCC compile farm and was able
> to play with it.
> 
> And, err, it's just that I had the logic reversed in the patch...  :-P

Hah, that's why we test :)

> The corrected version of the patch works for me, which is a big relief.
> 
> Could you give it a try too, just in case?

It works! Thanks a bunch.

> I'll see about running the whole GDB testsuite.

Thanks. From the outside, it seems surprising that GDB and binutils don't have
some kind of CI system that could catch regressions like this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30525] gdb cannot read shared libraries on SPARC64

[mattst88 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30525

--- Comment #11 from Matt Turner <mattst88 at gmail dot com> ---
I took a quick look at the mailing list and didn't see this patch. Is there
anything else needed before it can be reviewed?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30525] gdb cannot read shared libraries on SPARC64

[pedro at palves dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=30525

--- Comment #12 from Pedro Alves <pedro at palves dot net> ---
Sorry, just some more patience.  I am swamped with other things at the moment.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30525] gdb cannot read shared libraries on SPARC64

[pedro at palves dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=30525

--- Comment #13 from Pedro Alves <pedro at palves dot net> ---
Finally posted to the list:

 
https://inbox.sourceware.org/gdb-patches/20230705134141.1441753-1-pedro@palves.net/T/#u

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30525] gdb cannot read shared libraries on SPARC64

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30525

--- Comment #14 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Pedro Alves <palves@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=31a56a22c45d76df4c597439f337e3f75ac3065c

commit 31a56a22c45d76df4c597439f337e3f75ac3065c
Author: Pedro Alves <pedro@palves.net>
Date:   Wed Jun 7 10:38:14 2023 +0100

    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

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30525] gdb cannot read shared libraries on SPARC64

[sam at gentoo dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30525

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.1
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #15 from Sam James <sam at gentoo dot org> ---
All done, I think

-- 
You are receiving this mail because:
You are on the CC list for the bug.