[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