Re: [RFC] [gdb] Work around zero l_addr/l_ld

[Andrew Burgess <aburgess@redhat.com>]

Tom de Vries <tdevries@suse.de> writes:

> 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")
> - 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 replicating the missing glibc commit in
> svr4_solib_ops::read_lm_info.
>
> I've enabled the fix only for the configuration I can test, for all others I
> disabled it using "lmo.l_real_offset = -1".
>
> This is an RFC.  My question is: is the added complexity worth the trouble for
> what looks like a cornercase?

My take on this would be no, it's not worth the complexity.  It sounds
like the problem is caused by a glibc that has back-ported one part of a
fix, but missed the second part.  I would suggest that a better solution
would be to raise a bug against the downstream glibc port and get them
to back-port the second part of the fix (commit 88361b408b).

Thanks,
Andrew