This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Richard Henderson <rth@twiddle.net> writes:

> 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.

The linker change is minor.  Ideally the linker needs to know that the
new symbol is always defined.  Otherwise when linking a shared library
using --no-undefined the linker will issue inappropriate errors about
undefined references to the __tls_get_addr_sync_safe function.  At
least, that can happen with gold.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]