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

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

On 9/4/26 3:07 PM, Andrew Burgess wrote:
> 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).

Hi Andrew,

thanks for the review.

Your reasoning makes sense, and I can live with it.

I've submitted a bug ( https://bugs.almalinux.org/view.php?id=667 ).

Thanks,
- Tom