Don't expect the Apple supplied version of GCC to ever get this. Apple stopped
merging the GNU trunk of GCC in their own after it was relicensed under GPLv3.
They're still maintaining their own 4.2.x branch, but most of their efforts are
going to LLVM and Clang.
Le 2011-11-30 à 16:46, Walter Bright a écrit :
> 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.
>
> On 11/30/2011 12:57 PM, Jacob Carlborg wrote:
>>
>> On 21 nov 2011, at 20:12, Walter Bright wrote:
>>>
>>> On 11/21/2011 9:17 AM, Jacob Carlborg wrote:
>>>>
>>>>> One reason dmd doesn't support dynlib yet is because I haven't done much
>>>>> research into how dynlib actually works.
>>>>
>>>> Ok, I see. I though that you might know since you have developed a C++
>>>> compiler as well. I assume dynamic libraries can be used with DMC. Note
>>>> that when I say "dylib" I mean the general term "dynamic library" and not
>>>> the Mac OS X specific implementation.
>>>>
>>>
>>> DLLs on Windows work very differently from dynlibs on other systems. You
>>> have to approach each as its own animal.
>>
>> I've done some research about how TLS is implemented in the ELF format. I
>> don't understand everything but I think I've got a, at least, somewhat
>> better understanding of TLS.
>>
>> I've started to think about if it's possible to implement TLS on Mac OS X in
>> the same way as it's implement on Linux, but just with the help of the
>> compiler and druntime. From what I've read, and understood, what basically
>> happens and what's different compared to regular variables is:
>>
>> * Some form of relocation happens
>> * The TLS sections are initialization
>> * The regular sections are not used
>> * The regular symbol table is not used
>>
>> I'm not sure if ti's possible to do the relocation but the initialization
>> should be any problem (I think). I'm also not sure about the second symbol
>> table, if that can be made to work. This is how I'm thinking:
>>
>> There are a couple of things that needs to be done at program start to have
>> TLS working. It shouldn't matter if that's done by the dynamic linker or the
>> application itself (druntime). That's assuming an application can do
>> everything that needs to be done, i.e. relocation.
>>
>> Of course this is just how I'm thinking and I can be completely wrong. I
>> also have no idea how close your implementation of TLS on Mac OS X is to the
>> implementation on Linux.
>>
>> Now about getting TLS to work with dynamic libraries.
>>
>> What's happening now in the ___tls_get_addr function is that there is only
>> one TLS section/segment, bracketed by the __tls_beg and __tls_end segments.
>> The problem is that there is only one pari of these begin and end segments.
>> According to the TLS reference I read, a thread-local variable is identified
>> by a reference to the object and the offset of the variable in the
>> thread-local storage section. So the problem is now how to get the object in
>> which this variable is defined.
>>
>> I don't full understand how this object is accessed. I think it's either
>> passed to the __tls_get_addr function or accessed inside the function using
>> assembly instructions. What's passed to the __tls_get_addr is an argument of
>> the type "tls_index". The type is defined as follows for the IA-32 ABI:
>>
>> typedef struct
>> {
>> unsigned long int ti_module;
>> unsigned long int ti_offset;
>> } tls_index;
>>
>> Using the GNU variant of the ABI, the parameter is passed to the function in
>> the %eax register. The reference says that to load the thread pointer in the
>> %eax register the following code would be used:
>>
>> movl %gs:0, %eax
>>
>> I don't know if the object is the thread pointer or if it's the ti_module
>> field in the tls_index struct. The name would suggest it's the field in the
>> struct.
>>
>> To call the __tls_get_addr function the following assembly instructions are
>> used for the general dynamic model for the IA-32 ABI, the GNU version:
>>
>> 0x00 leal x@tlsgd(,%ebx,1),%eax
>> 0x07 call ___tls_get_addr@plt
>>
>> In the above code, "x" in the "leal" instruction, is the variable to be
>> accessed. Since you have already implemented TLS for Linux, I assume
>> according to this reference, you already know how to call this function
>> (depending on what TLS model is used).
>>
>> The general dynamic TLS model can be used everywhere and can access
>> variables defined anywhere else. There are other models available but these
>> are limited in different ways compared to the general model.
>>
>> I've also read your article at Dr. Dobb's about implementing TLS on Mac OS
>> X. You write:
>>
>> "my benchmarks show it to be 10 times slower than a simple access to a
>> shared global."
>>
>> I don't understand why it has to be like this. If TLS is implemented in the
>> same way as on Linux, but in the druntime instead of the dynamic linker (as
>> suggested in the beginning), I don't see why it would be any slower than on
>> Linux. I mean, the same tasks need to be performed regardless if it's done
>> by the dynamic linker or druntime.
>>
>> Also note that TLS is really fast on Mac OS X, pthread_getspecific is
>> implemented using three assembly instructions and pthread_self using two
>> instructions. There are inline versions available of these functions to
>> remove the function call overhead.
>>
>> BTW, according to this:
>>
>> http://stackoverflow.com/questions/2436772/thread-local-storage-macosx
>>
>> GCC 4.5+ on Mac OS X supports the __thread keyword but it's emulated.
>>
>> TLS reference: http://www.akkadia.org/drepper/tls.pdf
>>
>> --
>> /Jacob Carlborg
>>
>>
>> _______________________________________________
>> dmd-internals mailing list
>> [email protected]
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
> _______________________________________________
> dmd-internals mailing list
> [email protected]
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
--
Michel Fortin
[email protected]
http://michelf.com/
_______________________________________________
dmd-internals mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-internals
