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?
