This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PR18457] Don't require rtld lock to compute DTV addr for static TLS
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 03 Jun 2015 18:42:28 -0300
- Subject: Re: [PR18457] Don't require rtld lock to compute DTV addr for static TLS
- Authentication-results: sourceware.org; auth=none
- References: <orvbf5ffyt dot fsf at livre dot home> <20150603152448 dot GC32684 at spoyarek dot pnq dot redhat dot com> <or6174g2gb dot fsf at livre dot home> <20150603172402 dot GD32684 at spoyarek dot pnq dot redhat dot com>
On Jun 3, 2015, Siddhesh Poyarekar <siddhesh@redhat.com> wrote:
> Here's the core of my lack of understanding I guess - calling
> __tls_get_addr for an IE variable. Does that ever happen?
I guess it depends on what is meant by "IE variable".
I meant it as a TLS variable defined as part of the initial module set,
i.e., the main executable and the transitive closure of its
dependencies.
Now, if you understood it as a variable declared with the initial-exec
tls_model attribute, I apologize for the confusion.
>> I very much doubt it would have completed before the DTV race fix.
>> ___tls_get_addr would find the l_tls_offset for tst-join7mod.so to be
>> undecided, and would attempt to take the lock to make it forced dynamic.
>> Deadlock.
> I haven't tested that, but I did test with master and it works just
> fine. This is because __tls_get_addr doesn't get called at all when
> the variables are set as IE. And for that reason, I don't see why it
> shouldn't work otherwise.
Declaring the variable with IE tls_model will indeed go through a
completely different path. It is the GD tls_model, as in the patch for
the testcase that you posted, that will go through __tls_get_addr and
deadlock.
>> It's not clear to me that we want to make libc.so variables IE. If we
>> do, there are a number of others that could benefit from this treatment.
> These are static variables that are only referenced inside libc.so.
> Also, libc.so will always be loaded before the executable is running.
> I don't see why they shouldn't be IE.
The case to worry about is a static executable, that for whatever reason
doesn't get these variables linked in, but that dlopens some library
that depends on libc.so, which then brings these variables into the
running image. If libc.so had these variables as IE, this dlopen could
fail.
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer