This is the mail archive of the
mailing list for the glibc project.
Re: Async-signal-safe access to __thread variables from dlopen()ed libraries?
- From: Paul Pluzhnikov <ppluzhnikov at google dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, Richard Henderson <rth at twiddle dot net>, libc-alpha at sourceware dot org, Andrew Hunter <ahh at google dot com>
- Date: Wed, 18 Sep 2013 16:26:23 -0700
- Subject: Re: Async-signal-safe access to __thread variables from dlopen()ed libraries?
- Authentication-results: sourceware.org; auth=none
- References: <20120612193224 dot 8E43619060E at elbrus2 dot mtv dot corp dot google dot com> <4FD8D974 dot 7090903 at twiddle dot net> <20120613182826 dot 0CFAB2C0A3 at topped-with-meat dot com> <CALoOobMtXCw+oe7ZL0=my8YH5st8b1==CasS8i07z6G9DfaX-w at mail dot gmail dot com> <20120613210444 dot 659732C095 at topped-with-meat dot com> <mcr4nqebzok dot fsf at dhcp-172-18-216-180 dot mtv dot corp dot google dot com> <20120614002931 dot ABB762C08B at topped-with-meat dot com> <mcr1uliaeep dot fsf at dhcp-172-18-216-180 dot mtv dot corp dot google dot com>
Resurrecting an old thread ... which began here:
We really need a TLS that is both async-signal safe, and can be used from
dlopen()ed shared library.
On Wed, Jun 13, 2012 at 6:08 PM, Ian Lance Taylor <email@example.com> wrote:
> We are currently in an unpleasant situation where it is very easy and
> natural to use TLS variables--you just refer to them by name--and using
> them in a signal handler almost always works just fine. Except that in
> some highly specific but not completely implausible circumstances it
> crashes incomprehensibly. This is not a good thing, it's a lurking time
> Perhaps another approach would be to change __tls_get_addr to not use
> malloc, but to use mmap as needed. This of course assumes that mmap is
> in fact async signal safe although it is not on the approved list.
Andrew Hunter has proposed a Google-local glibc patch, that
- introduces async-signal-safe mmap-based allocator into elf/dl-misc.c, and
- updates the rest of the loader to use this allocator when getting space
for non-static TLS.
The allocator is currently quite simple, but wastes space. It could be
made more space-efficient independently of other changes.
Is this something that has a chance of being acceptable into trunk?