[cxx-abi-dev] thread_local summary

[John McCall]

On Oct 2, 2012, at 12:10 PM, Jason Merrill wrote:
> 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.

That works for me.

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

Right, it's definitely still worth documenting the conventions for this function
for implementations that want to use it.

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

Okay.  But the init function doesn't return a T&, right?  So we still need a
wrapper, and not only that, but a non-trivial wrapper that actually rederives
the address of the variable?  That seems unfortunate.

I would guess that the odds are that most translation units are only going
to define at most one single thread-local variable that needs dynamic
initialization.  Why don't we have the everything-in-the-TU init function return
a reference to the last thread_local variable it initializes?  That let you emit
at least one init function as an alias; for the rest you'll need stubs, but they
should be fairly small because they're in the defining translation unit.

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

Hmm.  Those of us not on ELF might need to go in a totally different
direction here.  I am not at all confident about making an alias to a
weak symbol, particularly when the referent is generally not semantically
equivalent.

John.