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: "Carlos O'Donell" <carlos at redhat dot com>
- To: Andrew Hunter <ahh at google dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Paul Pluzhnikov <ppluzhnikov at google dot com>
- Date: Fri, 06 Dec 2013 18:39:17 -0500
- Subject: Re: [PATCH] Async signal safe TLS accesses
- Authentication-results: sourceware.org; auth=none
- References: <CALoOobP6rTDosadvLKhHY+deDsU-FtvyO8QX_Y4dZy716e2ATQ at mail dot gmail dot com> <1386273671-13010-1-git-send-email-ahh at google dot com> <52A2475F dot 20303 at redhat dot com> <CADroS=7TtPaxpADezQ+U-NGrbF_iBVCaX8_g1pK+m54KTBSyAA at mail dot gmail dot com>
On 12/06/2013 05:50 PM, Andrew Hunter wrote:
> I'm looking into fixing TLDDESC. Is this the best available documentation:
>
> http://www.fsfla.org/~lxoliva/writeups/TLS/RFC-TLSDESC-x86.txt
>
> ?
As far as I know it is the canonical documentation for them.
> I note with some interest that using mask_all_signals whenever we take
> dl_load_lock would (very nearly, except for STB_GNU_UNIQUE symbols)
> solve the problem outright. I welcome comment from others as to
> whether this carries acceptable overhead.
>
> If not, I see two obvious possibilities
>
> - deprecate lazy relocations; I'm unclear if the gains from not doing
> a single dl_lookup_symbol_x per reloc at dlopen time are actually
> significant (though maybe I'm missing the point of lazy relocations?)
> AFAICT, the current scheme is more than capable of supporting the
> TLSDESC indirections that actually use __tls_get_addr and friends. I
> favor this scheme unless someone can tell me a good reason not to do
> so.
>
> - mask signals in _dl_tlsdesc_resolve_rela_fixup; use a dedicated
> lock instead of dl_load_lock in _dl_tlsdesc_resolve_early_return_p
> (easy). make dl_lookup_symbol_x async-signal-safe (ugh).
>
> Open to other suggestions as well.
Yes, I suggest:
- Declare GNU2 dialect TLS symbols AS-unsafe for the time being
and tackle it later.
Cheers,
Carlos.