Re: [PATCH] nptl: Move stack list variables into _rtld_global

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

On 2021-03-05 1:03 p.m., Florian Weimer wrote:
> Oh, that reads like a plausible explanation.  And I assume the
> non-attaching case, where GDB starts the process, is very different, and
> this ordering issue does not appear?

Indeed, in that case ld-linux-x86-64.so.2 is loaded before
libpthread.so.0 (ld-linux is necessarily loaded before the others, I
guess, since it's the one loading the others).  So the symbol is found:

    LOOKUP _rtld_global in ld-linux-x86-64.so.2
    Found 0x7ffff7ffd000

>> If we have to deal with this, I guess that GDB should now do things in a
>> different order: go through the whole library list and load their
>> symbols.  And then if one of those libraries were libpthread, try to
>> initialize libthread_db.
> 
> Initialization of libthread_db should be unconditional.  Programs use
> TLS data without linking against libpthread.  And glibc 2.34 might not
> have a separate libpthread at all.

Ok, currently GDB attempts to load libthread_db when noticing the main
objfile / program (I guess it is needed if the program is statically
linked to libpthread?) or when seeing a library named libpthread*.

I'm not sure how to fix this, other than making GDB attempt to load
libthread_db on every new shared library it notices, since that new
shared library may "finally" make it work.  The current code
specifically exists to avoid trying to load libthread_db for every new
shared library we notice, since that was considered wasteful.  Here's
the original thread about it:

  https://sourceware.org/pipermail/gdb-patches/2011-October/085781.html
  https://pi.simark.ca/gdb-patches/20111005182705.D744E2461D1@ruffy.mtv.corp.google.com/

About the hypothetical scenario for glibc 2.34: do you mean that the
pthread infrastructure will directly be in libc.so?  If so, our current
strategy of attempting to load libthread_db only for the main program
or a libpthread* library will indeed not work.  And I suppose that will
also require trying to load libthread_db on every new shared lib...

Simon