TLS for Android (and iOS)

[Joakim]

On Sunday, 30 March 2014 at 15:24:53 UTC, Dan Olson wrote:
> "Joakim" <joakim at airpost.net> writes:
> I think we can use their sections and it did not take long to 
> figure
> out.  Here is what an example link map has for one of my test 
> apps:
>
> 0x0004E22C	0x00000084	__DATA	__thread_vars
> 0x0004E2B0	0x0000000C	__DATA	__thread_data
> 0x0004E2BC	0x00000024	__DATA	__thread_bss
>
> The _thread_vars section has a TVLDescriptors for each thread 
> local.  It
> is used for caching the pthread_get/set key and has the 
> variable offset
> into the thread local chunk of memory that can be initialized 
> by copying
> _thread_data and _thread_bss (or just zerofill it).
---snip---
> A long way off from submitting anything to App Store.  With the 
> way
> things change, tlv may show up in a near future sdk, then this 
> just
> becomes a bridge.

Hmm, you and Jacob are probably right, it may be better to just 
follow what they do.

On Sunday, 30 March 2014 at 15:34:08 UTC, Dan Olson wrote:
> Jacob Carlborg <doob at me.com> writes:
>
>> I would follow the native TLS implementation in OS X, i.e. 
>> using
>> "tlv_get_addr", as close as possible. In theory it should be 
>> possible
>> to move the code from threadLocalVariables.c and 
>> threadLocalHelpers.s
>> directly in to druntime.
>>
>> Hopefully that would mean the same code for generating TLS 
>> access
>> could be used both on OS X and iOS.
>
> Do think we can just drop the dyld code into druntime? It 
> should work
> with perhaps some modifications, but I am not familiar with the 
> Apple
> opensource license. I should read it. It is BSD-like right?

I think the APSL is more similar to the CDDL, which was Sun's 
license for OpenSolaris and much of their open-source 
contributions, and requires that source is provided for 
APS-licensed files.  I think you could always add an APS-licensed 
file to druntime and the licenses would not clash, but that would 
make druntime not completely boost-licensed anymore, as the APSL 
has additional requirements than the minimal boost license.  It's 
probably best to just reimplement the necessary functions 
yourself.

> Would still
> need to hook in the garbage collector so it scans the thread 
> local
> memory.  I'll have to try it tonight.

David did this for the TLV code on OS X a year back, should be 
pretty straightforward to do something similar to what he did.

On Sunday, 30 March 2014 at 15:44:52 UTC, Dan Olson wrote:
> "Joakim" <joakim at airpost.net> writes:
>
>> I wonder if it'd be easier to pack your own Mach-O sections 
>> rather
>> than figuring out how to access all their sections and 
>> reimplementing
>> their TLV functions, assuming they're not available.  You 
>> might even
>> be able to do it as an llvm patch since the relevant lib/MC/ 
>> files
>> where llvm packs the TLS data into Mach-O sections seem pretty
>> straightforward.
>
> Thinking about this some more. It probably makes sense to have 
> an
> optional approach that can be used on any target that does not 
> have
> native TLS. This current approach for iOS will only work for 
> Mach-O. I
> wonder if the LLVM folks are working toward a generic TLS 
> without OS
> support.

Doesn't look like it, plus it'll need to be specialized for each 
object format, like Mach, ELF, or COFF, anyway.

After looking at the relevant llvm source for packing sections to 
see how it was working for you with Mach, I wonder if I won't be 
able to patch some of the existing llvm files for packing TLS 
data into ELF and get the TLS variables packed easily that way.  
I'll try that approach at some point.