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

[Pedro Alves <pedro@palves.net>]

On 16/04/21 18:33, Simon Marchi wrote:
> On 2021-04-16 1:18 p.m., Pedro Alves wrote:
>> On 16/04/21 17:53, Simon Marchi wrote:
>>
>>> Do we need / want to fix GDB if this goes in glibc then?  
>>
>> I think so.  We may need to discuss more the "needs_setup" hack, but we
>> can do that in that thread.
> 
> In the new version I add a new inferior flag "in_initial_library_scan".
> It's perhaps not ideal but the result is better than what I had in v1.
> But yeah let's discuss that in that thread.
> 
>> Given that libpthread.so is going away in the future, we should be thinking about
>> addressing that as well.  Does your patch fix that as side effect?
> 
> No, I think of that as a separate problem.
> 
>>
>> If not, GDB should be keying the loading of libthread_db.so on something else.
>> Making GDB try to load libthread_db in reaction to processing ld.so instead
>> libthread_db.so would fix that, I think.  And, it would fix this ordering problem at
>> hand as well.  So if we do that, maybe we don't need the other changes.
> 
> Is it possible to have a completely static executable that doesn't use
> ld.so but uses pthreads?

Yes, see gdb.threads/staticthreads.exp.  We handle that here, in linux-thread-db.c:

  /* Add ourselves to inferior_created event chain.
     This is needed to handle debugging statically linked programs where
     the new_objfile observer won't get called for libpthread.  */
  gdb::observers::inferior_created.attach (thread_db_inferior_created);

Or do you mean, a static executable that then later on loads (or loads something that loads)
libpthread.so, via dlopen?  In that case, libpthread.so pulls in ld.so.

> 
> I don't think that would work well for the "run" case, where ld-linux
> arrives before libpthreads.so (and before libc.so, for when pthreads is
> moved to libc.so).  If we try to load libthread_db when ld-linux
> appears, the symbols provided by libpthreads (or libc) won't be found.
> 
> We would have to key the loading on when both libpthread and ld-linux
> are there (or both libc and ld-linux).

Yeah, I think this would work - try to load libthread_db.so when:

  #1 ld-linux is processed, and,
  #2 libpthread is processed _and_ iff ld-linux has been processed already

Sounds like this should work for both run and attach, and for both
current glibc and future glibc.

> 
> Another problem with the current state (but that would be fixed with
> Florian's patch I think) is that gdb has this setting "set
> auto-solib-add".  If off, GDB won't load the symbols of shared
> libraries.  _Except_ if the library if libpthread:
> 
>   https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/solib.c;h=d32b2210005fdd6a5013cfd566620d6afeae9cf6;hb=HEAD#l968
> 
> But it means that if auto-solib-add is off, we won't load ld.so's
> symbols, and we fall back on the original problem, even if the ordering
> is right.  Since Florian's patch makes libthread_db only access symbols
> of libpthread.so, I think that avoids this issue as well.
> 
> But then when libpthreads is moved into libc, we'll have the problem
> that libthread_db simply won't get loaded...

Guess we should make GDB always read ld.so 's symbols as well, regardless of auto-solib-add.