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

[Richard Henderson]

On 2012-06-12 12:32, Paul Pluzhnikov wrote:
> 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?

I don't see why a linker change is necessary.  The only reason we do so
now is to enable linker relaxation.  It doesn't seem like the situations
in which this new builtin would be useful would be conducive to relaxation.



r~