Re: [PATCH glibc] nptl_db: different libpthread/ld.so load orders (bug 27744)

[Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>]

On 2021-04-16 12:47 p.m., Pedro Alves wrote:> On 16/04/21 17:43, Florian Weimer wrote:
>> * Pedro Alves:
>>
>>> On 16/04/21 17:28, Florian Weimer wrote:
>>>> * Pedro Alves:
>>>>
>>>>> IIRC, the order which libraries are loaded by GDB hasn't changed.  The
>>>>> issue is that until recently (before glibc 1daccf403b1b), the stacks
>>>>> lists lived in libpthread (stack_used/__stack_user), so the fact that
>>>>> GDB loaded libthread_db.so before ld.so's symbols were loaded didn't
>>>>> make a difference.  Now they were moved to ld.so, so libthread_db.so
>>>>> can't find them until GDB reads the ld.so symbols.  Is this assessment
>>>>> correct?
>>>>
>>>> Yes, I believe this is what happens.
>>>>
>>>
>>> OK, I believe what is confusing in your commit log was the reference to
>>> two different kinds of "loaded":
>>>
>>>   "libthread_db is loaded once GDB encounters libpthread, and at this
>>>   point, ld.so may not have been loaded yet. "
>>>
>>> The first loaded is about GDB dlopening libthread_db.so.  The second loaded
>>> refers to reading symbols -- ld.so has been loaded by the inferior already
>>> at that point.
>>>
>>> It would be clearer as:
>>>
>>>   "libthread_db is loaded once GDB encounters libpthread, and at this
>>>   point, ld.so's symbols may not have been read by GDB yet. "
>>
>> I'm going to go with:
>>
>> “
>> libthread_db is loaded once GDB encounters libpthread, and at this
>> point, ld.so may not have been processed by GDB yet.
>> ”
> 
> Sounds good.
> 
>>
>>> If I understood that correctly, then the following sentence is also a
>>> bit confusing:
>>>
>>>   "As a result, _rtld_global cannot be accessed by regular means from
>>>   libthread_db."
>>>
>>> Because that sounds to me like you were perhaps talking about some
>>> magic means to reference globals, some magic relocations, or some
>>> other magic voodoo only understood by glibc experts.
>>
>> We use the magic that GDB provides to us (ps_pglobal_lookup, I think).
>> I thought that this was understood by GDB experts only. 8-)
> 
> LOL
> 
> I skimmed the patch, and FWIW, it LGTM.  Just spotted a couple typos:
> 
>> +/* This test runs GDB against a forked copy of itself, to check
>> +   whether libthreaddb can be loaded, and that access to thread-local
> 
> libthreaddb -> libthread_db
> 
>> +/* This function implements the subprocess un der test.  It creates a
> 
> "un der" -> "under"
> 
> Thanks,
> Pedro Alves
> 

Do we need / want to fix GDB if this goes in glibc then?  I have an
updated version of my patch here [1] sitting here, that makes it work
with GDBserver as well, with the "broken" glibc 2.33.  I'm wondering if
I should post it or not.

Even without this bug, my patch can be beneficial from an efficiency
point of view, since it delays sending a qSymbol to the remote side
until all shared libraries are known.  But then it would be a completely
different rationale, I would have to word the commit message in terms of
"make things more efficient" rather than "fix a bug while attaching".

Simon

[1] https://sourceware.org/pipermail/gdb-patches/2021-April/177477.html