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: [PATCH] Async signal safe TLS accesses


On Wed, Oct 2, 2013 at 3:53 PM, Rich Felker <dalias@aerifal.cx> wrote:
> Since when does dlopen support initial-exec? I am not aware of any
> such support, and it certainly can't work in general since the needed
> address range might not even be available.
>

It certainly does since at least 2.15; I haven't searched the history
for its initial creation.  It, indeed, can fail; by default glibc
appears to allocate 1600 bytes/thread for "surplus" initial-exec TLS
(that is, that which is found in dlopen'd objects); dlopen will fail
if that is exhausted.

If I'm not mistaken, glibc even supports a feature where I can declare
a TLS variable in one dlopen'd object, and declare an extern reference
to it as initial-exec in another.  When the second dlopen completes,
we will attempt to force the OTHER object's variable into the surplus,
and fail if we're out of space or if someone has already accessed the
first TLS dynamically.

Please don't blame me for these features, as I neither created them
nor particularly value them for my systems.  I'm just saying that's
what we've got, and I would say it's general practice not to break
support for such things once released.

Hints on mailing lists imply opengl was one case where the feature was
needed, but I wasn't around the project that long ago :).


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