[cxx-abi-dev] thread_local CONstructors

[Jason Merrill]

On 09/20/2012 10:53 AM, Jason Merrill wrote:
> As discussed in N2659 it is possible to support
> dynamic initialization in just the compiler

...but there are major ABI implications for this as well.  Lazy 
initialization of TLS objects would be very similar to initialization of 
local statics, except that we need to initialize all the TLS objects in 
the TU, not just a single one.  So, something like

thread_local A a1, a2;
...
f(a1);

becomes (pseudo-code):

thread_local A_rep a1, a2;
void tls_init()
{
   static bool done;
   if (!done)
     {
       done = true;
       a1.A::A();
       __cxa_thread_atexit (A::~A, &a1);
       a2.A::A();
       __cxa_thread_atexit (A::~A, &a2);
     }
}

A& a1_f() { tls_init(); return a1; }
A& a2_f() { tls_init(); return a2; }
...
f(a1_f());

Unfortunately, since there is no way to tell whether a thread_local 
variable with external linkage has a dynamic initializer in another TU, 
we need to do the a1 to a1_f() transformation even for variables of POD 
type that are statically initialized.  I don't see a way to avoid this 
except doing POD initialization at thread creation time rather than 
lazily, which means significant changes outside the compiler.

So, the ABI questions are:

1) Do we want to do initialization lazily, at thread creation, or lazily 
except for PODs?
2) If lazy initialization, how do we mangle the singleton function a1_f?

Jason