March 04, 2015
"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
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
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
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
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
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
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
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
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
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 ;-)