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

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

On 9/11/26 5:05 PM, Tom de Vries wrote:
> +      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;
> +	}

I realized the last part of the comment is not formulated as precise as 
I want.

I've updated it to:
...
The target_read_memory is there to detect the improbable
situation that address 0 is mapped, in which case it might be the
address of the dynamic section.  */
...
and submitted a v2 ( 
https://sourceware.org/pipermail/gdb-patches/2026-September/230665.html 
), with two nits fixed as well.

Thanks,
- Tom