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

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2021-03-29 4:26 a.m., Florian Weimer wrote:> * Florian Weimer via Gdb-patches:
> 
>> * Simon Marchi:
>>
>>>>> 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*.
>>
>> Would it be possible to load libthread_db unconditionally after loading
>> all shared objects?  Then it is loaded only once.
>>
>>> 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...
>>
>> I think one attempt loading is enough, after all shared objects are
>> available.  In both the attaching and starting case, libpthread will be
>> seen by libthread_db if it is there.  I do not think it is necessary to
>> try loading libpthread_db again for each dlopen.  Maybe you could
>> restrict that to trigger on libpthread, but then dlopen of libpthread
>> does not really work today.
> 
> I would appreciate if we could make some progress on this issue.
> Please let me know if you need glibc test builds or something in that
> area.  Thanks.

Hi Florian,

I'll try to look into it, but I can't promise anything as I have nearly
zero free / personal time for GDB these days.

Simon