TLS for Android

Joakim joakim at airpost.net
Sat Mar 8 21:38:06 PST 2014


On Saturday, 8 March 2014 at 22:44:16 UTC, David Nadlinger wrote:
> On Sat, Mar 8, 2014 at 7:16 PM, Joakim <joakim at airpost.net> 
> wrote:
>> On Saturday, 8 March 2014 at 14:25:43 UTC, David Nadlinger 
>> wrote:
>>>
>>> LLVM does support putting variables into custom sections, and 
>>> you can more
>>> or less get away with the DMD bracketing approach (see e.g. 
>>> the new
>>> ModuleInfo discovery functionality I implemented for Linux, 
>>> which is the
>>> same as DMD's druntime uses).
>>
>> You're talking about findDataSection and friends?
>>
>> https://github.com/ldc-developers/druntime/blob/ldc/src/rt/sections_ldc.d#L115
>
> Not quite. I was referring to
> https://github.com/ldc-developers/druntime/blob/ldc-merge-2.064/src/rt/sections_linux.d
> (_d_dso_registry, ...) and the associated compiler-side
> implementation,
> https://github.com/ldc-developers/ldc/blob/5b14a5e5c4f292024afd8e5f520e837035942003/gen/module.cpp#L396.

Okay, I started looking around the master branch and didn't find 
what you were talking about.  No wonder, it's in the merge-2.064 
branch.  I'll look at what you did there.

>>> However, there is a catch: Due to what I can only imagine is 
>>> a bug, LLVM
>>> does not support emitting a symbol both into a custom section 
>>> and with weak
>>> linkage. Thus, you might be in for a round of LLVM hacking 
>>> either way, even
>>> though it will likely involve much less when going the DMD 
>>> route.
>>
>> Hmm, I guess this is why you don't use the bracketing approach 
>> anywhere?
>> What will be much less when going the DMD route?
>
> Actually, we didn't use the special section approach at all 
> until very
> recently (i.e. Martin's shared library changes in 2.064). And I 
> meant
> that you would probably get away with less LLVM hacking when 
> just
> changing the way LDC emits TLS globals/accesses than when 
> implementing
> "emulated" TLS on the LLVM backend side.

Well, the special section approach still isn't in the master 
branch, hence my confusion.  Okay, I wasn't clear that you were 
comparing the dmd route to having llvm generate the right pthread 
calls for Android.

>> As for reimplementing the runtime linker, in a sense that's 
>> what's being
>> done with dmd/druntime for OS X, where it implements it's own
>> ___tls_get_addr using pthread_setspecific.  I'll have to do 
>> the same for
>> Android, as bionic doesn't have a __tls_get_addr.
>
> Well, yes and no. I was specifically referring to keeping the 
> normal
> TLS infrastructure (i.e. %gs-based addressing on Linux/x86) in 
> place
> and just replacing the part that Glibc does (but Bionic 
> doesn't) with
> a piece of code in druntime. __tls_get_addr isn't necessarily 
> used on
> x86.

While Android/X86 TLS does use the %gs register 
(https://github.com/android/platform_bionic/blob/master/libc/private/__get_tls.h#L45), 
that's not portable and I'd like to try Android/ARM after this, 
so I'll stick with the pthread_(get|set)specific calls to wrap it:

https://github.com/android/platform_bionic/blob/master/libc/bionic/pthread_key.cpp


More information about the digitalmars-d-ldc mailing list