OS X libphobos2.so

[bitwise via Digitalmars-d]

On Saturday, 7 November 2015 at 08:37:40 UTC, Jacob Carlborg 
wrote:
> On 2015-11-06 19:46, bitwise wrote:
>
>> Currently, the compiler just calls ___tls_get_addr(void *p) to 
>> get the
>> thread local copy of a global. If that function signature is 
>> altered to
>> take a pointer to the image as well, the problem is solved.
>
> Hehe, you make it sound so easy. Perhaps I missed something and 
> you know more than I do. But as far as I know you have two 
> options:
>
> 1. Implement native TLS. This will require modifications to the 
> compiler and minor tweaks in the runtime
>
> 2. Continue to use the custom TLS implementation but add 
> support for dynamic libraries. This will require modifications 
> to the compiler (as you said above) and major changes to the 
> runtime
>
> The native TLS implementation works as you described above 
> (roughly). I can hardly believe that the code Apple added to 
> the dynamic linker to implement TLS is not necessary. I don't 
> see how you can get around not implementing the same code as 
> the dynamic linker does.
>
> I also think that this is a good opportunity to change to 
> native TLS. I don't like this situation we have now: "Yeah, D 
> is compatible with C, except TLS on OS X.".

Well, I'm speaking in relative terms when I say easy... ;)

Right now, TLS has a fairly simple implementation. DMD puts any 
global TLS vars into their own section in the binary. Then, at 
the point here those vars are accessed in code, DMD inserts a 
call to ___tls_get_addr(void*) to map the address of the var to 
some thread specific block of memory. When ___tls_get_addr() is 
called, it lazily instantiates a block of memory for the calling 
thread, memcpy's the TLS vars from the TLS section in the binary, 
and stores that thread local copy using pthread_set_specific(). 
Any subsequent calls to ___tls_get_addr() will simply use 
pthread_get_specific() to retrieve that block of memory, and map 
the received address to one pointing in that block.

So, since binaries will not be mapped to overlapping address 
spaces, I can loop over all the binary images and find the range 
to which the argument of ___tls_get_addr() belongs, and map the 
pointer to the appropriate block of memory.

I am concerned that looping over all binary images for each TLS 
access will have performance implications, but for now, this 
solution is good enough. Later, ___tls_get_addr() can be amended 
to pass a pointer to the image from which the TLS originated, 
allowing constant time lookup. I believe Martin has already done 
this for linux/fbsd, but I had time to look at this specific 
issue.

So.. I've got a basic implementation working at this point. The 
global ctors are now used instead of that infernal dyld callback 
to initialize sections. I've tried loading(dynamically) a shared 
library, and everything seems to work. Next on the list is to 
work on how all this interacts with threads. Martin seems to have 
already solved this too, so it should be fairly straight forward. 
Currently, linking a dylib statically throws "thread.d(2916): 
Unable to suspend thread", but other wise, seems to work as 
expected.

Anyways, I am open to any help on the TLS stuff if you've got 
time.

      Bit