[PATCH] nptl: Move stack list variables into _rtld_global
Simon Marchi
simon.marchi@polymtl.ca
Mon Mar 29 14:29:34 GMT 2021
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
More information about the Libc-alpha
mailing list