TLS for Android

Joakim joakim at airpost.net
Mon Mar 17 03:25:20 PDT 2014


On Sunday, 9 March 2014 at 18:23:00 UTC, Joakim wrote:
> On Sunday, 9 March 2014 at 16:12:19 UTC, David Nadlinger wrote:
>> So, if %gs works as expected on Android and the linker 
>> supports the necessary relocations, then it might be an option 
>> to simply use the existing TLS implementation in LLVM and 
>> simply provide the missing bits in druntime. On the other 
>> hand, if you choose to go with an entirely different TLS 
>> scheme (such as the DMD OS X implementation), you need to 
>> figure out how to change the codegen to emit the extra 
>> function calls to your __tls_get_addr analog, etc. Looking at 
>> llvm/lib/Target/ARM/ARMISelLowering.cpp, there might actually 
>> be a working implementation for this in LLVM already (which I 
>> didn't realize before), so this route would not necessarily be 
>> more complex than going with a different scheme. You'd 
>> probably just need to provide the __tls_get_addr 
>> implementation in druntime and figure out how LLVM emits the 
>> TLS image resp. how to get its base address.
> I think this is the best route, with the advantage that if my 
> ___tls_get_addr uses pthread_(get|set)specific, it will likely 
> just work on ARM too.  I thought I'd have to get ldc to 
> generate slightly different IR to do this, but it'd be great if 
> llvm already does this.  I had briefly looked at 
> X86ISelLowering.cpp but not the ARM one, I'll see what it does.

Alright, I looked into the ARM and X86 assembly lowering source 
and it appears that those __tls_get_addr calls are simply the 
ones put in for the dynamic thread models.  I tried hijacking 
those ___tls_get_addr calls by compiling all code as PIC, which 
forces a dynamic thread model in llvm that puts in the 
__tls_get_addr function calls, and then building as a shared 
library, which causes the gold linker to disable any linker 
optimizations that remove those calls.  However, the resulting 
shared library would not run because there are still a few TLS 
relocations from the GOT for the dynamic linker to execute and 
the Android dynamic linker doesn't do those TLS relocations.

So that was a deadend, looks like it's back to the packed TLS 
approach and having ldc generate IR that calls my __tls_get_addr 
manually.


More information about the digitalmars-d-ldc mailing list