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

[Pedro Alves <pedro@palves.net>]

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

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.

Pedro Alves

> I assume that ldd shows objects in link map order, the it looks like
> this:
> 
> $ ldd /usr/bin/python3
> 	linux-vdso.so.1 (0x00007fff1f8d5000)
> 	libpython3.9.so.1.0 => /lib64/libpython3.9.so.1.0 (0x00007f3fd7782000)
> 	libc.so.6 => /lib64/libc.so.6 (0x00007f3fd75b7000)
> 	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3fd7595000)
> 	libdl.so.2 => /lib64/libdl.so.2 (0x00007f3fd758e000)
> 	libutil.so.1 => /lib64/libutil.so.1 (0x00007f3fd7589000)
> 	libm.so.6 => /lib64/libm.so.6 (0x00007f3fd7443000)
> 	/lib64/ld-linux-x86-64.so.2 (0x00007f3fd7af7000)
> 
> Thanks,
> Florian
>