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

[Pedro Alves <pedro@palves.net>]

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.

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?

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.

> I have an
> updated version of my patch here [1] sitting here, that makes it work
> with GDBserver as well, with the "broken" glibc 2.33.  I'm wondering if
> I should post it or not.

> 
> Even without this bug, my patch can be beneficial from an efficiency
> point of view, since it delays sending a qSymbol to the remote side
> until all shared libraries are known.  

Right, I like batching for this reason.

> But then it would be a completely
> different rationale, I would have to word the commit message in terms of
> "make things more efficient" rather than "fix a bug while attaching".
>