What is the state of D with Android/iOS

[Joakim via Digitalmars-d]

On Wednesday, 4 March 2015 at 17:31:49 UTC, Dan Olson wrote:
> Dan Olson <zans.is.for.cans at yahoo.com> writes:
>>
>> For Android, LDC generates the usual .tbss/.tdata sections for 
>> TLS vars
>> and __aeabi_read_tp() when needed to lookup the base address.
>>
>>   ldc2 -mtriple=thumbv7-linux-anrdoideabi -output-s test.d
>>
>>   tlsvar = 42;
>>
>> 	ldr	r1, .LCPI1_0
>> 	movs	r2, #42
>> 	bl	__aeabi_read_tp
>> 	str	r2, [r0, r1]
>>
>> For iOS, I then added what was missing from the OS loader to 
>> find TLS
>> sections and provide the lookup function to lazy init TLS 
>> block and
>> return address.  These are just linked in with the app instead 
>> being
>> provided by OS libs and kernel.  At that point, it looked to
>> ldc_sections.d like normal OSX TLS.
>>
>> I would guess you could do the same for Android/ARM with LDC 
>> and make it
>> look like linux to ld_sections.
>
> As PIC:
>   ldc2 -mtriple=thumbv7-linux-androideabi -output-s 
> -relocation-model=pic -O tls1.d
>
> 	ldr	r0, .LCPI1_0
> .LPC1_0:
> 	add	r0, pc
> 	bl	__tls_get_addr(PLT)
> 	movs	r1, #42
> 	str	r1, [r0]
>
> Shouldn't that work?

Maybe the inserted function call will work- I'm not familiar with 
ARM assembly, so I can't say for sure- but I'm guessing it's 
passing a different pointer to the function, which I noted above. 
  Some modifications will likely need to be made to llvm to 
support the packed TLS scheme used so far, with dmd for 
Android/x86.