On Wednesday, 4 March 2015 at 17:31:49 UTC, Dan Olson wrote:
Dan Olson <[email protected]> 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.