[PATCH] nptl_db: do not link libthread_db.so with dt-relr

[Florian Weimer]

* Carlos O'Donell via Libc-alpha:

> On 6/2/22 10:12, Paul E Murphy via Libc-alpha wrote:
>> 
>> 
>> On 6/1/22 1:56 PM, Adhemerval Zanella wrote:
>>> 
>>> 
>>> On 01/06/2022 14:46, Paul E. Murphy via Libc-alpha wrote:
>>>> Should libthread_db.so be dlopen-able by gdb running with a
>>>> slightly older glibc without dt-relr support?  If not, I can
>>>> rework this to mark these tests unsupported in such cases.
>>>> 
>>>> ---8<---
>>>> 
>>>> This may be loaded by a host gdb linked against a libc which does
>>>> not support dt-relr.  tst-gdb-pthread-attach{,-static} fails on
>>>> powerpc64 whose linker supports dt-relr, but the host libc does
>>>> not.
>>>> 
>>>> Trying host libthread_db library:
>>>> .../build/glibc/nptl_db/libthread_db.so.1. dlopen failed:
>>>> /lib64/libc.so.6: version `GLIBC_ABI_DT_RELR' not found (required
>>>> by .../build/glibc/nptl_db/libthread_db.so.1).
>>> 
>>> I think it does make sense to disable DT_RELR for libthread_db.so
>>> mainly as an improvement for the testsuite regression tests,
>>> although I am not sure if the scenario of trying to use a gdb
>>> without DT_RELR with a binary that requires DT_RELR would be that
>>> usual (it would either require the binary or the gdb to have non
>>> standard loader paths).
>> 
>> It is an unlikely combination, but not so improbable that we've run
>> into with two of our CI configurations.
>> 
>> Is this OK to submit?  I don't think this failure is unique to ppc64.
>> However, I am still curious about what, if any, compatibility
>> guarantees nptl_db has.
>  
> Your CI configurations are incorrectly setup.
>
> You must match nptl_db with the runtime.
>
> We only support a matched loader, runtime, and nptl_db.

Uhm … I'm not sure if I agree.

Looking at nptl/tst-pthread-gdb-attach.c, we do not run gdb under the
glibc being tested.  Instead, the test assumes that the libthread_db we
just built can be loaded by the system glibc.  But it may not support
DT_RELR, so it could lead to test failure.  I expect that the
pretty-printer tests are similar.

So it's not the CI setup is wrong, it's our testsuite.  I think we
should do something to avoid this spurious failure.  Running GDB under
an explicit loader invocation will not necessarily work if the built
glibc is older than the system glibc.  Given that, Paul's patch is not
unreasonable.  We really should avoid such spurious test failures.

Alternatively, we could try to get DT_RELR into those distributions that
can be used easily for glibc development.

Thanks,
Florian