[PATCH] [gdb] Detect corrupt link map with zero l_ld and l_addr

[Tom de Vries <tdevries@suse.de>]

On ppc64le-linux (AlmaLinux 9.8), I run into:
...
FAIL: gdb.mi/mi-dlmopen.exp: still-in-use fields were all correct
...

While investigating this, I stumbled on this warning emitted during the
calculation of allow_dlmopen_tests:
...
(gdb) run ^M
Starting program: allow_dlmopen_tests.x ^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
warning: .dynamic section for "/lib64/ld64.so.2" is not at the expected \
  address (wrong library or version mismatch?)^M
dlmopen debug supported.^M
...

The warning is mentioned in this glibc commit 88361b408b:
...
    elf: Copy l_addr/l_ld when adding ld.so to a new namespace

    When add ld.so to a new namespace, we don't actually load ld.so.  We
    create a new link map and refers the real one for almost everything.
    Copy l_addr and l_ld from the real ld.so link map to avoid GDB warning:

    warning: .dynamic section for ".../elf/ld-linux-x86-64.so.2" is not at \
      the expected address (wrong library or version mismatch?)

    when handling shared library loaded by dlmopen.
...

So, AFAICT the setup is:
- the glibc package is based on v2.34
- it contains a backport of commit a93d9e03a3 ("Extend struct r_debug to
  support multiple namespaces [BZ #15971]")
- it doesn't contain a backport of commit 88361b408b ("elf: Copy l_addr/l_ld
  when adding ld.so to a new namespace") [1]
- both commits are part of v2.35

What happens is:
- when probing for l_addr and l_ld in svr4_solib_ops::read_lm_info, both get
  the value 0
- in svr4_solib_ops::lm_addr_check, the 0 value propagates to l_dynaddr, and
  "l_addr = l_dynaddr - dynaddr" then underflows, and things go downhill from
  there, resulting in the warning and eventually the FAIL.

Fix this by detecting the situation in svr4_solib_ops::read_so_list, and
bailing out with a warning.

Add detection of this and other "corruption" warnings in allow_dlmopen_tests
to make sure the related test-cases are skipped.

In more detail, before this patch we have:
...
$ gdb -q -batch outputs/gdb.base/dlmopen/dlmopen -ex start -ex next \
    -ex "pipe info shared | ld64"
  ...
warning: .dynamic section for "/lib64/ld64.so.2" is not at the expected \
  address (wrong library or version mismatch?)
  ...
0x00007ffff7f80000  0x00007ffff8000000  0         Yes         /lib64/ld64.so.2
0x0000000000000160  0xffffffffffff0000  1         Yes         /lib64/ld64.so.2
...
and after:
...
warning: Corrupted shared library entry: zero l_addr and l_ld
warning: Corrupted shared library entry: zero l_addr and l_ld
  ...
0x00007ffff7f80000  0x00007ffff8000000  0         Yes         /lib64/ld64.so.2
...

Alternatively, we could prevent the underflow in svr4_solib_ops::lm_addr_check:
...
  bool l_addr_updated = false;
  if (l_dynaddr >= dynaddr)
    {
      l_addr = l_dynaddr - dynaddr;
      l_addr_updated = true;
    }

  if (l_addr_updated
      && (l_addr & (minpagesize - 1)) == 0
      && (l_addr & align) == ((l_dynaddr - dynaddr) & align))
...
but we'd still get an incorrect range:
...
warning: .dynamic section for "/lib64/ld64.so.2" is not at the expected \
  address (wrong library or version mismatch?)
  ...
0x00007ffff7f80000  0x00007ffff8000000  0         Yes         /lib64/ld64.so.2
0x0000000000060000  0x0000000000080000  1         Yes         /lib64/ld64.so.2
...

FTR, in an earlier attempt I proposed to deal with the FAIL using an
xfail [1].  And in an another attempt I proposed to deal with it by
replicating the glibc fix in gdb [3].

Tested on ppc64le-linux and x86_64-linux.

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

[1] https://bugs.almalinux.org/view.php?id=667
[2] https://sourceware.org/pipermail/gdb-patches/2026-July/229073.html
[3] https://sourceware.org/pipermail/gdb-patches/2026-August/229549.html
---
 gdb/solib-svr4.c          | 23 +++++++++++++++++++++++
 gdb/testsuite/lib/gdb.exp |  3 +++
 2 files changed, 26 insertions(+)

diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c
index c4af1b11a4d..50a94170cb3 100644
--- a/gdb/solib-svr4.c
+++ b/gdb/solib-svr4.c
@@ -1333,6 +1333,29 @@ svr4_solib_ops::read_so_list (svr4_info *info, CORE_ADDR lm, CORE_ADDR prev_lm,
       if (*name == '\0' || match_main (name.get ()))
 	continue;
 
+      gdb_byte dummy;
+      if (li->l_addr_inferior == 0 && li->l_ld == 0
+	  && target_read_memory (0, &dummy, 1) != 0)
+	{
+	  /* We have l_addr_inferior == 0 and l_ld == 0 (corresponding to link
+	     map entries l_addr and l_ld).  This can happen with a glibc that:
+	     - has commit a93d9e03a3 ("Extend struct r_debug to support
+	       multiple namespaces [BZ #15971]"), but
+	     - misses commit 88361b408b ("elf: Copy l_addr/l_ld when adding
+	       ld.so to a new namespace").
+	     This seems to be the case at least for the alma linux 9.8 BaseOS
+	     version, which uses glibc v2.34 and backports only the first
+	     commit ( https://bugs.almalinux.org/view.php?id=667 ).
+	     Detect this here and bail out.  Otherwise, we'll present
+	     the user with incorrect info for "info shared".
+
+	     The target_read_memory is there to detect the improbable
+	     situation that address 0 is both mapped, and the address of the
+	     dynamic section.  */
+	  warning (_("Corrupted shared library entry: zero l_addr and l_ld"));
+	  return 0;
+	}
+
       sos.emplace_back (name.get (), std::move (li));
     }
 
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 1ebdaf6ba10..06ebf65e921 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -3201,6 +3201,9 @@ gdb_caching_proc allow_dlmopen_tests {} {
 	return 0
     }
     gdb_expect {
+	-re "warning: Corrupted.*$gdb_prompt $" {
+	    set allow_dlmopen_tests 0
+	}
 	-re "$inferior_exited_re normally.*${gdb_prompt} $" {
 	    set allow_dlmopen_tests 1
 	}

base-commit: 0855b93cfb911a4feab76a31bb1914982b3e6979
-- 
2.51.0