[dmd-internals] Building Phobos and druntime as a dylib on Mac OS X

[Jacob Carlborg]

On 2 dec 2011, at 21:27, Walter Bright wrote:

> 
> 
> On 12/1/2011 11:48 AM, Jacob Carlborg wrote:
>> On 30 nov 2011, at 22:46, Walter Bright wrote:
>> 
>>> I'm waiting for gcc on the Mac to support TLS, which it must do soon. When it does, I'll change dmd to match it.
>> 
>> That was kind of a disappointing answer.
>> 
> 
> What that means is there's a ton of work to do on dmd, and implementing TLS three times is a waste of effort. dmd will eventually have to match what the default C compiler does on the Mac.

I can understand that. I was naively thinking that we could implement it the same way it's implemented for ELF and assuming Apple would implemented it like that as well. Then we would only need to change the compiler now and not later. I was wrong about that, see below.

> I'm also not terribly concerned if TLS access is slow, only that it is correct. This is because a program that depends on fast TLS access is badly designed, for several reasons.

Fair enough. I was thinking it would be easier to implement support for dynamic libraries if TLS was implemented "properly". If that also would mean that accessing thread local variables would be faster, than all the better.

> And lastly, if you wish to work on the OSX TLS, I do appreciate the efforts. I think it can only help. Please look at how clang is doing it, if it is doing it.


Sean mentioned that TLS is supported natively in Mac OS X Lion. I've downloaded the source code for dyld, the release that ships with Lion and it seems to be correct. There's a function called "tlv_get_addr" that seems to be doing the same as "__tls_get_addr" does on Linux. It looks a bit different from the ELF implementation, different function names and similar, but it seems to be doing the same thing.

Now to the question: how should we implement this? Do we have two implementations, a new implementation targeting 10.7 and the existing one for all previous versions of Mac OS X? Or do we want to just have one implementation, somehow.

-- 
/Jacob Carlborg