From: Florian Weimer <fw@deneb.enyo.de>
To: <gdb-patches@sourceware.org>
Cc: Simon Marchi <simon.marchi@polymtl.ca>,
Simon Marchi via Libc-alpha <libc-alpha@sourceware.org>
Subject: Re: [PATCH] nptl: Move stack list variables into _rtld_global
Date: Mon, 29 Mar 2021 10:26:58 +0200 [thread overview]
Message-ID: <87a6qmwejx.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <871rctbf2z.fsf@oldenburg.str.redhat.com> (Florian Weimer via Gdb-patches's message of "Fri, 05 Mar 2021 20:00:52 +0100")
* 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.
next prev parent reply other threads:[~2021-03-29 8:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-13 15:10 Florian Weimer
2020-11-16 18:02 ` Adhemerval Zanella
2021-03-05 16:54 ` Simon Marchi
2021-03-05 17:15 ` Florian Weimer
2021-03-05 17:26 ` Andreas Schwab
2021-03-05 17:58 ` Simon Marchi
2021-03-05 18:03 ` Florian Weimer
2021-03-05 18:45 ` Simon Marchi
2021-03-05 19:00 ` Florian Weimer
2021-03-29 8:26 ` Florian Weimer [this message]
2021-03-29 14:29 ` Simon Marchi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a6qmwejx.fsf@mid.deneb.enyo.de \
--to=fw@deneb.enyo.de \
--cc=gdb-patches@sourceware.org \
--cc=libc-alpha@sourceware.org \
--cc=simon.marchi@polymtl.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).