What is the state of D with Android/iOS

[Dan Olson via Digitalmars-d]

"Rishub Nagpal" <rishubster at gmail.com> writes:

> On Wednesday, 25 February 2015 at 08:04:02 UTC, Joakim wrote:
>> On Tuesday, 24 February 2015 at 21:20:24 UTC, Rishub Nagpal wrote:
>>> On Tuesday, 24 February 2015 at 19:34:15 UTC, Joakim wrote:
>>>> I need to patch llvm in a similar way to that dmd PR, so that
>>>> Android/ARM can use the same scheme.  It appears that Dan did
>>>> something similar with his patched llvm for iOS.
>>>>
>>>> As for your linked Android patches, that might be possible but
>>>> would be pointless unless you are only deploying to a device you
>>>> patched the OS for.  Better to patch llvm to support the same TLS
>>>> scheme used for Android/x86.
>>>
>>> Interesting. A few others and I were talking about getting
>>> Android/ARM to function with LDC today. I'll be sure to keep up
>>> to date with your work!
>>
>> The remaining piece is to insert the correct function call to
>> ___tls_get_addr when TLS variables are accessed, ie the equivalent
>> to this patch for dmd's backend needs to be created for llvm:
>>
>> https://github.com/joakim-noah/dmd/commit/477f52cffb0d8bd1a698dd33ad7e2e66d9fa62ca#diff-d427199c5cd504da634c0c42fc2b3371
>>
>> I've been putting off looking into llvm's internals enough to write
>> that for a while now.  If you or anybody else knows llvm better,
>> feel free to take it.  The remaining changes needed are in this
>> small patch for llvm:
>>
>> https://gist.github.com/joakim-noah/1fb23fba1ba5b7e87e1a
>
> Why exactly do we need to insert that TLS function call? Shouldn't
> Android/ARM follow the normal ELF logic? I am not really sure what Dan
> Olsen did here:
>
> https://github.com/smolt/llvm/commit/42c2d7057b62454bb466abe8d146dd3c717e2cc5
>
> Is he creating a iOS TLS ABI?
>
>
> I have spent the last week doing heavy research, and I am not sure if
> I really understand the problem
>
> Do you have any references or documented code I can read to better
> understand what exactly is going on?

I haven't been following this discussion, so forgive me if this is way
off.

I think LDC/LLVM should work as-is for Android/ARM if you are happy with
linux thread local sections and lookup func.  For iOS the situation is a
bit worse since LLVM did not have code to generate the TLS lookup
function, but it did know how to generate Mach-O TLS sections.

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.
--
Dan