Async-signal-safe access to __thread variables from dlopen()ed libraries?

[Paul Pluzhnikov]

Resurrecting an old thread ... which began here:
https://sourceware.org/ml/libc-alpha/2012-06/msg00335.html

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 <iant@google.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
> bomb.
...
> 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?

Thanks,
-- 
Paul Pluzhnikov