This is the mail archive of the
mailing list for the glibc project.
Async-signal-safe access to __thread variables from dlopen()ed libraries?
- From: ppluzhnikov at google dot com (Paul Pluzhnikov)
- To: libc-alpha at sourceware dot org
- Cc: ppluzhnikov at google dot com, iant at google dot com
- Date: Tue, 12 Jun 2012 12:32:24 -0700 (PDT)
- Subject: Async-signal-safe access to __thread variables from dlopen()ed libraries?
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
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
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?