[cxx-abi-dev] thread_local summary

Jason Merrill jason at redhat.com
Tue Oct 2 19:10:32 UTC 2012


On 10/02/2012 01:40 PM, John McCall wrote:
> FWIW, this all seems basically reasonable to me, at least for the most
> general case.  I think we're going to need a way to declare that a variable
> doesn't have dynamic initialization — mandating a call basically ruins the
> more efficient TLS models.

Yep.  At the moment, in my implementation the way to do that is to use 
__thread instead of thread_local.  I'm not sure we need a different 
mechanism.

> Formally, the wrapper function doesn't seem to be ABI here — it's just a
> recommendation for saving code size and relocations at the access site.

True.  But since it's COMDAT, so the mangled name is exposed to the linker.

> Taking the address of a function leads to pretty awful code.  I suggest that
> we guarantee the existence of an init function in obvious cases, like when
> the type is non-POD.  In this case, we can just call the init function, right?

Right, I forgot to mention that.

> For mangling, I think we should just follow the pattern for guard variables —
> pick some 2-character prefix and drop the function type.  So something
> like _ZTH6my_var.

OK.

> It looks like static data members of class templates fall out naturally here,
> with the init function becoming COMDAT.

The init function symbol is an alias to the function that initializes 
all the thread_local variables defined in a translation unit.  For a 
variable with vague linkage, the alias should be weak.

Jason



More information about the cxx-abi-dev mailing list