This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PR18457] Don't require rtld lock to compute DTV addr for static TLS


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]