This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Async signal safe TLS accesses
- From: Rich Felker <dalias at aerifal dot cx>
- To: Andrew Hunter <ahh at google dot com>
- Cc: Ian Lance Taylor <iant at google dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Paul Pluzhnikov <ppluzhnikov at google dot com>
- Date: Wed, 2 Oct 2013 19:14:43 -0400
- Subject: Re: [PATCH] Async signal safe TLS accesses
- Authentication-results: sourceware.org; auth=none
- References: <523F2ED8 dot 8090909 at redhat dot com> <1379977289-21260-1-git-send-email-ahh at google dot com> <20130924025738 dot GK20515 at brightrain dot aerifal dot cx> <524C3467 dot 2030503 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1310022203420 dot 22120 at digraph dot polyomino dot org dot uk> <CAKOQZ8wN0ecYROnxNT5edV5yxr5jiAuoLVg4ErO9DZq3SYj4HQ at mail dot gmail dot com> <20131002223612 dot GA20515 at brightrain dot aerifal dot cx> <CADroS=6qkwBbdq8M0Lq7_k0p3oB+asnhcPnEyrrzu65MUAd0rQ at mail dot gmail dot com> <20131002225311 dot GB20515 at brightrain dot aerifal dot cx> <CADroS=4E1f2UOJa5_QCHr+9-P1ksXmrKbyXPVrWmEgL0o=diYg at mail dot gmail dot com>
On Wed, Oct 02, 2013 at 04:03:01PM -0700, Andrew Hunter wrote:
> 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.
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.
Rich