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

[Florian Weimer]

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

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

Thanks,
Florian