March 04, 2015 Re: What is the state of D with Android/iOS | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rishub Nagpal | "Rishub Nagpal" <rishubster@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 |
March 04, 2015 Re: What is the state of D with Android/iOS | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rishub Nagpal | On Tuesday, 3 March 2015 at 21:20:35 UTC, Rishub Nagpal wrote: > On Wednesday, 25 February 2015 at 08:04:02 UTC, Joakim wrote: >> 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 referred you to my dmd PR above with more details. The third comment there goes over it all, with additional links to articles and the TLS implementation in druntime for Android: https://github.com/D-Programming-Language/dmd/pull/3643#issuecomment-45479519 As I said before, Android does not support native TLS, just as OS X did not when Walter wrote his TLS implementation for OS X. If you read his article, you will get the idea of what we're doing. In any case, you don't really need to understand everything in order to add the missing piece. Similar to how llvm already adds a call to ___tls_get_addr(tls_index* ti) when compiled with PIC, we need to add a call to ___tls_get_addr(void* p) when a TLS variable is invoked to pull the right pointer offset in our Android scheme. Right now, I'm just trying it on x86, as you can see in my gist above, before attempting the same on ARM. If you or someone else is already familiar with llvm internals, they can do this quicker than me. If not, I'll get to it eventually. |
March 04, 2015 Re: What is the state of D with Android/iOS | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dan Olson | Dan Olson <zans.is.for.cans@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? |
March 05, 2015 Re: What is the state of D with Android/iOS | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dan Olson | On Wednesday, 4 March 2015 at 17:31:49 UTC, Dan Olson wrote:
> Dan Olson <zans.is.for.cans@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.
|
April 12, 2015 Probably you can run a D command line app on an android ARM device | ||||
---|---|---|---|---|
| ||||
Posted in reply to Joakim | BTW - since we have linux on ARM, the following may be useful if you wish to run a D application on your Android mobile device. No ADB or root required. http://kevinboone.net/android_nonroot.html I guess you might be able to run a local web server to have a friendlier interface, although I have not yet tried. Since ssh and rsync works, I don't see why a web server wouldn't. Only thing is that I don't think vibe.d is available on ARM yet. (Please correct me if I am wrong). The alternative is to run a full linux install in a chroot: https://play.google.com/store/apps/details?id=ru.meefik.linuxdeploy |
April 13, 2015 Re: Probably you can run a D command line app on an android ARM device | ||||
---|---|---|---|---|
| ||||
Posted in reply to Laeeth Isharc | On Sunday, 12 April 2015 at 19:03:33 UTC, Laeeth Isharc wrote:
> BTW - since we have linux on ARM, the following may be useful if you wish to run a D application on your Android mobile device. No ADB or root required.
>
> http://kevinboone.net/android_nonroot.html
>
> I guess you might be able to run a local web server to have a friendlier interface, although I have not yet tried. Since ssh and rsync works, I don't see why a web server wouldn't.
>
> Only thing is that I don't think vibe.d is available on ARM yet. (Please correct me if I am wrong).
>
> The alternative is to run a full linux install in a chroot:
>
> https://play.google.com/store/apps/details?id=ru.meefik.linuxdeploy
I am pretty sure I remember people reporting running vibe.d on Raspberry Pi
It is not checked by CI so things can break time to time, but in general it should work
|
April 13, 2015 Re: Probably you can run a D command line app on an android ARM device | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | On Monday, 13 April 2015 at 05:57:24 UTC, Dicebot wrote:
> On Sunday, 12 April 2015 at 19:03:33 UTC, Laeeth Isharc wrote:
>> BTW - since we have linux on ARM, the following may be useful if you wish to run a D application on your Android mobile device. No ADB or root required.
>>
>> http://kevinboone.net/android_nonroot.html
>>
>> I guess you might be able to run a local web server to have a friendlier interface, although I have not yet tried. Since ssh and rsync works, I don't see why a web server wouldn't.
>>
>> Only thing is that I don't think vibe.d is available on ARM yet. (Please correct me if I am wrong).
>>
>> The alternative is to run a full linux install in a chroot:
>>
>> https://play.google.com/store/apps/details?id=ru.meefik.linuxdeploy
>
> I am pretty sure I remember people reporting running vibe.d on Raspberry Pi
> It is not checked by CI so things can break time to time, but in general it should work
Is there a need for people running tests on Raspberry Pis? I'm planning on picking up the new version in a few days, was unaware D even really worked on ARM.
|
April 13, 2015 Re: Probably you can run a D command line app on an android ARM device | ||||
---|---|---|---|---|
| ||||
Posted in reply to weaselcat | On Monday, 13 April 2015 at 06:37:34 UTC, weaselcat wrote:
> Is there a need for people running tests on Raspberry Pis? I'm planning on picking up the new version in a few days, was unaware D even really worked on ARM.
Currently vibe.d uses Travis CI so unless it gets replaced with some self-hosted CI solution I don't think anything can really be done here right now. Well, apart from trying it out and reporting bugs if there are any :)
|
April 13, 2015 Re: Probably you can run a D command line app on an android ARM device | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot Attachments:
| 2015-04-13 7:57 GMT+02:00 Dicebot via Digitalmars-d < digitalmars-d@puremagic.com>:
> On Sunday, 12 April 2015 at 19:03:33 UTC, Laeeth Isharc wrote:
>
>> BTW - since we have linux on ARM, the following may be useful if you wish to run a D application on your Android mobile device. No ADB or root required.
>>
>> http://kevinboone.net/android_nonroot.html
>>
>> I guess you might be able to run a local web server to have a friendlier interface, although I have not yet tried. Since ssh and rsync works, I don't see why a web server wouldn't.
>>
>> Only thing is that I don't think vibe.d is available on ARM yet. (Please
>> correct me if I am wrong).
>>
>> The alternative is to run a full linux install in a chroot:
>>
>> https://play.google.com/store/apps/details?id=ru.meefik.linuxdeploy
>>
>
> I am pretty sure I remember people reporting running vibe.d on Raspberry Pi It is not checked by CI so things can break time to time, but in general it should work
>
I did compile and run a Vibe.d based solution on a Raspi B for almost 18
months.
It was mainly for the client part though, but I didn't have any issue
specific to Vibe.d.
|
April 13, 2015 Re: Probably you can run a D command line app on an android ARM device | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | Am Mon, 13 Apr 2015 06:45:35 +0000 schrieb "Dicebot" <public@dicebot.lv>: > On Monday, 13 April 2015 at 06:37:34 UTC, weaselcat wrote: > > Is there a need for people running tests on Raspberry Pis? I'm planning on picking up the new version in a few days, was unaware D even really worked on ARM. > > Currently vibe.d uses Travis CI so unless it gets replaced with some self-hosted CI solution I don't think anything can really be done here right now. Well, apart from trying it out and reporting bugs if there are any :) It's possible to emulate ARM using qemu on travis-ci: http://www.tomaz.me/2013/12/02/running-travis-ci-tests-on-arm.html Of course it's not exactly fast ;-) |
Copyright © 1999-2021 by the D Language Foundation