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

[Carlos O'Donell]

On 6/2/22 10:54, Florian Weimer wrote:
> * 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.

The just built nptl_db must be matched to the libc you just built.
 
> 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.

We should fix this.

> 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.

I'm OK with Paul's patch if it has a big comment that says this is not the correct
solution, and that the right solution is to run everything, gdb included, under
an explicit loader invocation, and maybe even look at 'set exec-wrapper.'

We *can* run gdb under an explicit loader invocation, but if we can't start that gdb
then those tests will have to fail as unsupported. This is a consequence of
having a dependency on system tools that themselves must run in the same execution
image with the just-built runtime.

In order to decouple this we need to get rid of nptl_db :-)

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

Absolutely.

-- 
Cheers,
Carlos.