On 2015-11-09 18:30, bitwise wrote:

The AA is not needed. The offset of the TLS var is known at compile
time.

I was thinking instead of iterating over all loaded images. Something that could be done without modifying the compiler.

If you look at sections_elf_shared.d you can see the signature of
__tls_get_addr, and that it takes a pointer to the struct tls_index or
something. *if* I understand correctly, one of the two vars in that
struct is the index of the image, and the other is the offset into the
imag's tls section. Not sure where/hoe that struct is outputted though.
So you would have to figure out how to get the backend to do the same
thing for OSX. I think the image index may have to be assigned at load
time, but I'm not sure.

If we're going to modify the backend it's better to match the native implementation.

I looked a bit at the implementation. For each TLS variable it outputs two symbols (at least if the variable is initialized). One with the same name as the variable, and one with the variable name plus a prefix, "$tlv$init". The symbol with the prefix contains the actual value which the variable is initialized in the source code with.

The other symbol is a struct looking something like this:

struct TLVDescriptor
{
    void* function (TLVDescriptor*) thunk;
    size_t key;
    size_t offset;
}

The dynamic loader will, when an image is loaded, set "thunk" to a function implemented in the dynamic loader. "key" is set to a key created by "pthread_key_create". It then maps the key to the currently loading image.

I think the compiler access the variable as if it were a global variable of type "TLVDescriptor". Then calls the thunk passing in the variable itself.

So the following code:

int a = 3;

void foo() { auto b = a; }

Would be lowered to:

TLVDescriptor _a;
int _a$tlv$init = 3;

void foo()
{
    TLVDescriptor tmp = _a;
    int b = cast(int) tmp.thunk(&tmp);
}

When the compiler stores the symbol in the image it would only need to set the offset since the dynamic loader sets the other two fields.

Although I'm not sure how the "_a$tlv$init" symbol is used. If the dynamic loader completely handles that or if the compiler need to do something with that.

The enhancement request for implementing native TLS contains some information [1].

The amount of code to actually do it should be
trivial, it's reading/interpreting the backend that will be the problem ;)

Yeah, I agree :)

[1] https://issues.dlang.org/show_bug.cgi?id=9476#c2

--
/Jacob Carlborg

Reply via email to