[PATCH glibc] nptl_db: different libpthread/ld.so load orders (bug 27744)
Pedro Alves
palves@redhat.com
Fri Apr 16 16:25:15 GMT 2021
On 16/04/21 17:07, Simon Marchi wrote:
>
> Can this state (libpthread loaded, ld.so not loaded) really happen
> during the normal lifetime of a process? My understanding is that this
> state happens when attaching only because GDB reads the shared libraries
> from the process in an undefined order, so libpthread may be discovered
> before ld.so. So we present to libthread_db a state that doesn't really
> make sense.
I don't think it's random from GDB's perspective -- GDB reads the shared library
list of out of the link map, so it should be reading them in link map order.
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?
Pedro Alves
More information about the Libc-alpha
mailing list