This is the mail archive of the 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 02, 2013 at 04:03:01PM -0700, Andrew Hunter wrote:
> On Wed, Oct 2, 2013 at 3:53 PM, Rich Felker <> 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.

In that case, our current discussion does not apply. TLS allocated
into the "surplus" initial TLS zone would be handled the same as it is
now, not via anything new under present discussion.

> 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.

Lovely... It would be really nice if this usage could be deprecated.
The last part ("or if someone has already accessed the first TLS
dynamically") is the most depressing...

> 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.

Yes. Anyway I don't think the current discussion has any bearing on
this. This discussion is about dynamic TLS allocation, not allocation
of the "surplus" initial-exec space.

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

Note that the gnu2 dynamic TLS model would have handled this much
better. It makes very-efficient (just as efficient as initial-exec)
access to dynamic TLS possible when the DSO is initially loaded or
when there is sufficient surplus initial TLS space for it, but also
allows a fallback mechanism (slower but non-failing/non-crashing) when
it's not possible.


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