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

[ppluzhnikov at google dot com (Paul Pluzhnikov)]

Greetings,

When writing CPU or heap profilers, one frequently desires to have fast
and async-signal-safe access to thread-local variables.

The __thread variables generally fit the bill (at least on Linux/x86),
when the variable is in the main executable, or in a directly-linked DSO.

But when the DSO is dlopen()ed (and does not use initial-exec TLS model),
the first access to TLS variable from a given thread triggers a call to
malloc (with the following stack):

#0  0x00007f10ea319c97 in malloc () from /lib64/libc.so.6
#1  0x00007f10eac75b6c in tls_get_addr_tail () from /lib64/ld-linux-x86-64.so.2
#2  0x00007f10eac76760 in __tls_get_addr () from /lib64/ld-linux-x86-64.so.2
#3  ... profiler accessing __thread variable ...
#4 <signal handler>
...

The profiler can often tolerate the __thread variable being unavailable
(we just don't record that sample), but can not tolerate the malloc call.

Ian Lance Taylor proposed the following mechanism:

  I think you need a compiler change, perhaps

    void *__builtin_async_safe_tls_address(VAR)

  that takes a TLS variable as an argument and returns either the address
  of that variable, or NULL.  The compiler would turn this into a call
  to __tls_get_addr_async_safe.  The linker knows about the magic symbol
  __tls_get_addr, so the linker would have to change to recognize the new
  function as well.
...
  It seems like a general problem.  Clearly signal handlers want to be
  able to refer to TLS variables, and clearly signal handlers can not call
  malloc.  So this would be a way of finessing that.  Though it would of
  course be better to make TLS variables be reliable when referenced from
  signal handlers.

Before we embark on a (long) journey to implement any of this ...

- Do others have the desire to access TLS variables from signal handlers,
  from dynamically loaded code?

- Are there currently working solutions for this we haven't considered,
  or better approaches than the one Ian proposed?

Thanks!
--
Paul Pluzhnikov