www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - Building for ARM with LDC

reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
Hello all,

I decided to start trying out the ARM embedded programming ideas 
in Adam Ruppe's D Cookbook.  Speaking as a complete newcomer to 
this area of programming, I was wondering: although Adam advises 
using GDC in his tutorials, would it be possible to use LDC 
instead -- and if so, what to use in place of the calls to 
arm-gdcproject-linux-gnueabi-gdc, 
arm-gdcproject-linux-gnueabi-as, arm-gdcproject-linux-gnueabi-ld, 
and arm-gdcproject-linux-gnueabi-objcopy ... ?

I'm building LDC on top of llvm 3.4, so is the ARM support here 
adequate in any case?

Thanks & best wishes,

     -- Joe
Jul 13 2014
next sibling parent reply "Mike" <none none.com> writes:
On Sunday, 13 July 2014 at 10:16:36 UTC, Joseph Rushton Wakeling 
wrote:

 Hello all,

 I decided to start trying out the ARM embedded programming 
 ideas in Adam Ruppe's D Cookbook.  Speaking as a complete 
 newcomer to this area of programming, I was wondering: although 
 Adam advises using GDC in his tutorials, would it be possible 
 to use LDC instead -- and if so, what to use in place of the 
 calls to arm-gdcproject-linux-gnueabi-gdc, 
 arm-gdcproject-linux-gnueabi-as, 
 arm-gdcproject-linux-gnueabi-ld, and 
 arm-gdcproject-linux-gnueabi-objcopy ... ?

 I'm building LDC on top of llvm 3.4, so is the ARM support here 
 adequate in any case?

 Thanks & best wishes,

     -- Joe


Are you targeting ARM (e.g. Cortex-A), or ARM Thumb (e.g 
Cortex-M)?
Jul 13 2014
parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Sunday, 13 July 2014 at 10:53:06 UTC, Mike wrote:

 Are you targeting ARM (e.g. Cortex-A), or ARM Thumb (e.g 
 Cortex-M)?


Cortex-M, I believe.  But as all I'm doing for now is qemu-based 
I guess I can adapt to either.
Jul 13 2014
parent reply "Mike" <none none.com> writes:
On Sunday, 13 July 2014 at 12:42:41 UTC, Joseph Rushton Wakeling 
wrote:

 On Sunday, 13 July 2014 at 10:53:06 UTC, Mike wrote:

 Are you targeting ARM (e.g. Cortex-A), or ARM Thumb (e.g 
 Cortex-M)?


 Cortex-M, I believe.  But as all I'm doing for now is 
 qemu-based I guess I can adapt to either.


The very first compiler I used to make my semihosted hello world 
(http://wiki.dlang.org/Minimal_semihosted_ARM_Cortex-M_%22Hello_World%22) 
was LDC.  I haven't used it in while, though I intend to when I 
get a little farther with my project.

Once again, my goal was to have a compiler that I could use to 
create a D runtime, so I didn't need phobos or the D Runtime.  I 
don't know how many people know this, but you don't actually need 
the D Runtime to program in D.  You just have to keep yourself 
limited to a C-like subset of D.

If you want to use structs, however, you will need to give the 
compiler some phony TypeInfo stuff from the object.d/di file.  
See my example here: 
(https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/blob/master/1.3-struc
s/source/object.d). 
  I wrote a wiki about this too 
(https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/wiki/1.3-Structs). 
  This also needs to be done for GDC.  LDC would crash if I did 
not provide them 
(https://github.com/ldc-developers/ldc/issues/552).  Some of 
these issues seem to have been fixed 
(https://github.com/ldc-developers/ldc/issues/551), but I haven't 
gotten around to testing them and providing feedback.

Adam Ruppe actually recommended a potential solution to this 
nonsense (https://issues.dlang.org/show_bug.cgi?id=12270).

Also with LDC, I don't think there is a linker capable of 
creating an executable for ARM Cortex-M.  You can build binutils, 
or you can use the linker from here GNU Tools for ARM Embedded 
(https://launchpad.net/gcc-arm-embedded).

LDC folks, Does LLVM have its own linker?

LDC also needs to be built with an ARM Thumb LLVM backend. I did 
this, but I lost my script files :(  I'll have to recreate them.  
I remember it being much simpler than GDC.  I've asked the LDC 
folks to include an ARM Thumb backend in their release, but I 
don't think they've done it yet.  On Arch Linux, the LDC package 
seems to already include ARM Thumb:

ldc2 --version
LDC - the LLVM D compiler (0.13.0):
   based on DMD v2.064 and LLVM 3.4.2
   Default target: x86_64-unknown-linux-gnu
   Host CPU: corei7
   http://dlang.org - http://wiki.dlang.org/LDC

   Registered Targets:
     aarch64  - AArch64 (ARM 64-bit target)
     arm      - ARM
     cpp      - C++ backend
     hexagon  - Hexagon
     mips     - Mips
     mips64   - Mips64 [experimental]
     mips64el - Mips64el [experimental]
     mipsel   - Mipsel
     msp430   - MSP430 [experimental]
     nvptx    - NVIDIA PTX 32-bit
     nvptx64  - NVIDIA PTX 64-bit
     ppc32    - PowerPC 32
     ppc64    - PowerPC 64
     ppc64le  - PowerPC 64 LE
     r600     - AMD GPUs HD2XXX-HD6XXX
     sparc    - Sparc
     sparcv9  - Sparc V9
     systemz  - SystemZ
     thumb    - Thumb
     x86      - 32-bit X86: Pentium-Pro and above
     x86-64   - 64-bit X86: EM64T and AMD64
     xcore    - XCore


Mike
Jul 13 2014
next sibling parent reply "Trass3r" <un known.com> writes:
 LDC folks, Does LLVM have its own linker?


http://lld.llvm.org/#current-status
Jul 13 2014
parent reply "Mike" <none none.com> writes:
On Sunday, 13 July 2014 at 14:33:57 UTC, Trass3r wrote:

 LDC folks, Does LLVM have its own linker?


 http://lld.llvm.org/#current-status


Does LDC employ this linker, and is it possible to provide 
custome linker scripts?
Jul 17 2014
parent "Trass3r" <un known.com> writes:
 http://lld.llvm.org/#current-status


 Does LDC employ this linker?


No. It's alpha.
Jul 17 2014
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Sunday, 13 July 2014 at 13:35:19 UTC, Mike wrote:

 On Arch Linux, the LDC package seems to already include ARM 
 Thumb


btw if you have any suggestions for building default gdc / ldc 
packages in Arch Linux to make those better suitable for embedded 
experiments, please either write me via public dicebot.lv or add 
an issue here : https://github.com/Dicebot/Arch-PKGBUILDs

I am very interested in making this experience as easy to try out 
as possible for random intrigued by-passers.
Jul 13 2014
parent reply "Mike" <none none.com> writes:
On Sunday, 13 July 2014 at 15:29:19 UTC, Dicebot wrote:

 On Sunday, 13 July 2014 at 13:35:19 UTC, Mike wrote:

 On Arch Linux, the LDC package seems to already include ARM 
 Thumb


 btw if you have any suggestions for building default gdc / ldc 
 packages in Arch Linux to make those better suitable for 
 embedded experiments, please either write me via 
 public dicebot.lv or add an issue here : 
 https://github.com/Dicebot/Arch-PKGBUILDs

 I am very interested in making this experience as easy to try 
 out as possible for random intrigued by-passers.


I think if users are somehow aware that there will be no runtime 
or phobos it may be ok to create a distributable package.  But if 
user's expect everything to just work, they may come away 
disappointed.

We may be able to bundle the newlib C library and a phony 
object.d for the runtime.  But, I wouldn't want users' first 
experience with D on microcontrollers to leave them with a bad 
taste in their mouth.  I'll have to think about it some more.  
I'm not sure right now.
Jul 14 2014
parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 15 July 2014 at 00:56:31 UTC, Mike wrote:

 I think if users are somehow aware that there will be no 
 runtime or phobos it may be ok to create a distributable 
 package.  But if user's expect everything to just work, they 
 may come away disappointed.

 We may be able to bundle the newlib C library and a phony 
 object.d for the runtime.  But, I wouldn't want users' first 
 experience with D on microcontrollers to leave them with a bad 
 taste in their mouth.  I'll have to think about it some more.  
 I'm not sure right now.


I currently define runtime/phobos as virtual dependencies so it 
is perfectly possible to provide alternative runtime package 
tuned for microcontrollers.
Jul 15 2014
prev sibling parent reply "master" <djj shumtn.com> writes:
 LDC also needs to be built with an ARM Thumb LLVM backend. I 
 did this, but I lost my script files :(  I'll have to recreate 
 them.  I remember it being much simpler than GDC.  I've asked 
 the LDC folks to include an ARM Thumb backend in their release, 
 but I don't think they've done it yet.  On Arch Linux, the LDC 
 package seems to already include ARM Thumb:

 ldc2 --version
 LDC - the LLVM D compiler (0.13.0):
   based on DMD v2.064 and LLVM 3.4.2
   Default target: x86_64-unknown-linux-gnu
   Host CPU: corei7
   http://dlang.org - http://wiki.dlang.org/LDC

   Registered Targets:
     aarch64  - AArch64 (ARM 64-bit target)
     arm      - ARM
     cpp      - C++ backend
     hexagon  - Hexagon
     mips     - Mips
     mips64   - Mips64 [experimental]
     mips64el - Mips64el [experimental]
     mipsel   - Mipsel
     msp430   - MSP430 [experimental]
     nvptx    - NVIDIA PTX 32-bit
     nvptx64  - NVIDIA PTX 64-bit
     ppc32    - PowerPC 32
     ppc64    - PowerPC 64
     ppc64le  - PowerPC 64 LE
     r600     - AMD GPUs HD2XXX-HD6XXX
     sparc    - Sparc
     sparcv9  - Sparc V9
     systemz  - SystemZ
     thumb    - Thumb
     x86      - 32-bit X86: Pentium-Pro and above
     x86-64   - 64-bit X86: EM64T and AMD64
     xcore    - XCore


 Mike



C:\Users\xxx>ldc2 --version
LDC - the LLVM D compiler (0.13.0):
   based on DMD v2.064 and LLVM 3.4.2
   Default target: i686-pc-mingw32
   Host CPU: penryn
   http://dlang.org - http://wiki.dlang.org/LDC

   Registered Targets:
     x86    - 32-bit X86: Pentium-Pro and above
     x86-64 - 64-bit X86: EM64T and AMD64

C:\Users\xxx>

windows platform only two target?

Registered Targets:
     x86    - 32-bit X86: Pentium-Pro and above
     x86-64 - 64-bit X86: EM64T and AMD64
???
Jul 18 2014
parent reply "Kai Nacke" <kai redstar.de> writes:
Hi master!

On Friday, 18 July 2014 at 13:32:44 UTC, master wrote:

 windows platform only two target?


As there are still serious problems with cross compiling we do 
only provide binaries for x86 / x86_64 targets.

As soon as I have fixed the floating point issue (see 
https://github.com/ldc-developers/ldc/pull/643) it makes sense to 
provide binaries with more targets.

Regards,
Kai
Jul 19 2014
parent reply "Joakim" <dlang joakim.airpost.net> writes:
On Saturday, 19 July 2014 at 18:51:16 UTC, Kai Nacke wrote:

 Hi master!

 On Friday, 18 July 2014 at 13:32:44 UTC, master wrote:

 windows platform only two target?


 As there are still serious problems with cross compiling we do 
 only provide binaries for x86 / x86_64 targets.

 As soon as I have fixed the floating point issue (see 
 https://github.com/ldc-developers/ldc/pull/643) it makes sense 
 to provide binaries with more targets.


Can you make available whatever scripts/patches/config you're 
currently using to cross-compile for ARM?  I want to try it out, 
in preparation for getting Android/ARM working.
Aug 11 2014
parent reply "Kai Nacke" <kai redstar.de> writes:
Hi Joakim!

On Monday, 11 August 2014 at 09:44:56 UTC, Joakim wrote:

 On Saturday, 19 July 2014 at 18:51:16 UTC, Kai Nacke wrote:

 Hi master!

 On Friday, 18 July 2014 at 13:32:44 UTC, master wrote:

 windows platform only two target?


 As there are still serious problems with cross compiling we do 
 only provide binaries for x86 / x86_64 targets.

 As soon as I have fixed the floating point issue (see 
 https://github.com/ldc-developers/ldc/pull/643) it makes sense 
 to provide binaries with more targets.


 Can you make available whatever scripts/patches/config you're 
 currently using to cross-compile for ARM?  I want to try it 
 out, in preparation for getting Android/ARM working.


For cross-compiling you need to use the pull request 643. Setting 
CC to the right gcc compiler (gcc-linux-arm) should be all you 
have to do.

Regards,
Kai
Aug 11 2014
parent reply "Joakim" <dlang joakim.airpost.net> writes:
On Tuesday, 12 August 2014 at 04:38:09 UTC, Kai Nacke wrote:

 Hi Joakim!

 On Monday, 11 August 2014 at 09:44:56 UTC, Joakim wrote:

 On Saturday, 19 July 2014 at 18:51:16 UTC, Kai Nacke wrote:

 Hi master!

 On Friday, 18 July 2014 at 13:32:44 UTC, master wrote:

 windows platform only two target?


 As there are still serious problems with cross compiling we 
 do only provide binaries for x86 / x86_64 targets.

 As soon as I have fixed the floating point issue (see 
 https://github.com/ldc-developers/ldc/pull/643) it makes 
 sense to provide binaries with more targets.


 Can you make available whatever scripts/patches/config you're 
 currently using to cross-compile for ARM?  I want to try it 
 out, in preparation for getting Android/ARM working.


 For cross-compiling you need to use the pull request 643. 
 Setting CC to the right gcc compiler (gcc-linux-arm) should be 
 all you have to do.


Thanks for the info, I'll try your pull request.

What does setting CC to gcc-linux-arm do, invoke the ARM linker?  
How do I make sure druntime/phobos are compiled for ARM?

Just so it's clear, I want to compile ldc as a linux/x86 binary 
that will generate ARM code on an x86 host, then compile 
druntime, phobos, and their unit tests as ARM libraries/binaries 
to deploy to an ARM target.
Aug 11 2014
parent reply "Kai Nacke" <kai redstar.de> writes:
Hi Joakim!

On Tuesday, 12 August 2014 at 04:51:00 UTC, Joakim wrote:

 On Tuesday, 12 August 2014 at 04:38:09 UTC, Kai Nacke wrote:

 Hi Joakim!

 On Monday, 11 August 2014 at 09:44:56 UTC, Joakim wrote:

 On Saturday, 19 July 2014 at 18:51:16 UTC, Kai Nacke wrote:

 Hi master!

 On Friday, 18 July 2014 at 13:32:44 UTC, master wrote:

 windows platform only two target?


 As there are still serious problems with cross compiling we 
 do only provide binaries for x86 / x86_64 targets.

 As soon as I have fixed the floating point issue (see 
 https://github.com/ldc-developers/ldc/pull/643) it makes 
 sense to provide binaries with more targets.


 Can you make available whatever scripts/patches/config you're 
 currently using to cross-compile for ARM?  I want to try it 
 out, in preparation for getting Android/ARM working.


 For cross-compiling you need to use the pull request 643. 
 Setting CC to the right gcc compiler (gcc-linux-arm) should be 
 all you have to do.


 Thanks for the info, I'll try your pull request.

 What does setting CC to gcc-linux-arm do, invoke the ARM 
 linker?  How do I make sure druntime/phobos are compiled for 
 ARM?


Yes, the CC setting is used to invoke the linker.


 Just so it's clear, I want to compile ldc as a linux/x86 binary 
 that will generate ARM code on an x86 host, then compile 
 druntime, phobos, and their unit tests as ARM 
 libraries/binaries to deploy to an ARM target.


Cross-compiling druntime/phobos is possible but untried. You
could try to setup host and target compilers in CMakeList.txt or
you could build a small script to compile all .d modules into a
library. There is no out-of-the-box solution.
(Currently I build ldc on an ARM box and avoid the cross
compiling scenario.)

Regards,
Kai
Aug 13 2014
parent reply "Joakim" <dlang joakim.airpost.net> writes:
On Wednesday, 13 August 2014 at 16:21:28 UTC, Kai Nacke wrote:

 Cross-compiling druntime/phobos is possible but untried. You
 could try to setup host and target compilers in CMakeList.txt or
 you could build a small script to compile all .d modules into a
 library. There is no out-of-the-box solution.
 (Currently I build ldc on an ARM box and avoid the cross
 compiling scenario.)


OK, I figured.  I'll try something similar to what Dan did on iOS 
(http://forum.dlang.org/thread/m2txc2kqxv.fsf comcast.net), as he 
didn't have that native compilation option either.
Aug 13 2014
parent reply "Joakim" <dlang joakim.airpost.net> writes:
On Thursday, 14 August 2014 at 01:56:04 UTC, Joakim wrote:

 On Wednesday, 13 August 2014 at 16:21:28 UTC, Kai Nacke wrote:

 Cross-compiling druntime/phobos is possible but untried. You
 could try to setup host and target compilers in CMakeList.txt 
 or
 you could build a small script to compile all .d modules into a
 library. There is no out-of-the-box solution.
 (Currently I build ldc on an ARM box and avoid the cross
 compiling scenario.)


 OK, I figured.  I'll try something similar to what Dan did on 
 iOS (http://forum.dlang.org/thread/m2txc2kqxv.fsf comcast.net), 
 as he didn't have that native compilation option either.


An update: by simply following in Dan's footsteps for iOS, but 
with slightly different flags for linux/ARM, I've been able to 
build an x86 ldc binary and an ARM druntime/phobos in a linux/x86 
VM and deploy to a linux/ARM device. :)

I'm able to build the dmd sample program sieve.d for ARMv7 with 
all three combinations of ldc alone, ldc and druntime, and ldc 
and phobos, with small modifications to sieve.d for writing 
output for each case.  The first two combos produce an executable 
that runs fine on linux/ARM, the one with phobos seems to run and 
then prints out junk output.


compile for ARM.  Right now, I push the objects and static 
libraries to the linux/ARM target and link them using the native 
linker, as I didn't want to mess with trying to figure out how to 
get the x86 linker to link for ARM yet.

I'm going to try cross-compiling and running the unit tests next. 
  What should I expect?

I'll try merging David's old patch for ARM exception-handling
Aug 26 2014
parent reply "Kai Nacke" <kai redstar.de> writes:
On Tuesday, 26 August 2014 at 11:54:02 UTC, Joakim wrote:

 On Thursday, 14 August 2014 at 01:56:04 UTC, Joakim wrote:

 On Wednesday, 13 August 2014 at 16:21:28 UTC, Kai Nacke wrote:

 Cross-compiling druntime/phobos is possible but untried. You
 could try to setup host and target compilers in CMakeList.txt 
 or
 you could build a small script to compile all .d modules into 
 a
 library. There is no out-of-the-box solution.
 (Currently I build ldc on an ARM box and avoid the cross
 compiling scenario.)


 OK, I figured.  I'll try something similar to what Dan did on 
 iOS 
 (http://forum.dlang.org/thread/m2txc2kqxv.fsf comcast.net), as 
 he didn't have that native compilation option either.


 An update: by simply following in Dan's footsteps for iOS, but 
 with slightly different flags for linux/ARM, I've been able to 
 build an x86 ldc binary and an ARM druntime/phobos in a 
 linux/x86 VM and deploy to a linux/ARM device. :)

 I'm able to build the dmd sample program sieve.d for ARMv7 with 
 all three combinations of ldc alone, ldc and druntime, and ldc 
 and phobos, with small modifications to sieve.d for writing 
 output for each case.  The first two combos produce an 
 executable that runs fine on linux/ARM, the one with phobos 
 seems to run and then prints out junk output.


 compile for ARM.  Right now, I push the objects and static 
 libraries to the linux/ARM target and link them using the 
 native linker, as I didn't want to mess with trying to figure 
 out how to get the x86 linker to link for ARM yet.

 I'm going to try cross-compiling and running the unit tests 
 next.
  What should I expect?


I still have trouble with binaries compiled without optimization. 
Using -O1 or higher works.


 I'll try merging David's old patch for ARM exception-handling 



I merged the easy part of the patch so expect some merge 
conflicts.

BTW: sounds real cool!

Regards,
Kai
Aug 26 2014
parent reply "Joakim" <dlang joakim.airpost.net> writes:
On Tuesday, 26 August 2014 at 17:04:41 UTC, Kai Nacke wrote:

 On Tuesday, 26 August 2014 at 11:54:02 UTC, Joakim wrote:

 I'm going to try cross-compiling and running the unit tests 
 next.
 What should I expect?


 I still have trouble with binaries compiled without 
 optimization. Using -O1 or higher works.


Yes, I ran into this also: it tries to run some module ctor and 
dies, but only if compiled with -O0.

My question is more how many of the unit tests should I expect to 
run?


 I'll try merging David's old patch for ARM exception-handling 



 I merged the easy part of the patch so expect some merge 
 conflicts.


Yep, I noticed that, had to slightly modify your long double 
patch in one place to get it to apply also.
Aug 26 2014
next sibling parent "Joakim" <dlang joakim.airpost.net> writes:
On Tuesday, 26 August 2014 at 17:56:09 UTC, Joakim wrote:

 My question is more how many of the unit tests should I expect 
 to run?


Alright, finally got the tests to link and run.

All tests pass for a cross-compiled linux/ARM druntime except for 
rt.minfo, which crashes.  I noticed that core.internal.convert 
and core.internal.hash aren't run by the ldc test scripts, so I 
compiled and ran those too.  The latter passes, but the former 
asserts in one of the conversions and fails.  I haven't looked 
into which conversion yet, may be related to the real/long double 
cross-compiling issues.

As for phobos, three modules' unit tests don't compile for 
linux/ARM- std.variant, std.math, and std.traits- and every 
single module throws this error when running their tests right 
now:

core.exception.RangeError std.string.sformat(0): Range violation

Something basic is going wrong there, will look into it more.

How does this compare to the test runs on ARM that the ldc devs 
have tried?
Aug 28 2014
prev sibling parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
Hi Joakim,

On 26/08/14 19:56, Joakim via digitalmars-d-ldc wrote:

 My question is more how many of the unit tests should I expect to run?
 […]
 I'll try merging David's old patch for ARM exception-handling from



When I last tried (which was a _long_ time ago), there were still some 
random crashes in the unit tests that looked like they were caused by an 
error during unwinding.

Back then, my guess was that there might be a subtle mistake in the 
ARM-specific unwinding definitions (type size, field alignment, …) or an 
unhandled special case in the code. It's probably fairly easy to figure 
out with a more methodical look at the issue, but I was in "get 
something to work, now" mode when I hacked up the patch.

Let me know if there are any questions regarding EH that I might be able 
to help you with.

Best,
David
Aug 30 2014
parent reply "Joakim" <dlang joakim.airpost.net> writes:
On Saturday, 30 August 2014 at 21:58:18 UTC, David Nadlinger via 
digitalmars-d-ldc wrote:

 When I last tried (which was a _long_ time ago), there were 
 still some random crashes in the unit tests that looked like 
 they were caused by an error during unwinding.


If you mean random in the sense that the same test will sometimes 
pass and sometimes crash, I haven't seen that.


 Back then, my guess was that there might be a subtle mistake in 
 the ARM-specific unwinding definitions (type size, field 
 alignment, …) or an unhandled special case in the code. It's 
 probably fairly easy to figure out with a more methodical look 
 at the issue, but I was in "get something to work, now" mode 
 when I hacked up the patch.

 Let me know if there are any questions regarding EH that I 
 might be able to help you with.


I haven't actually looked at either the real/longdouble patch or 
your EH patch other than skimming them yet, just applied the two 
and tried different ways of building the resulting source.  I've 
now tried building with gcc and clang, both native and 
cross-compile for each, and find almost no difference in the test 
runs done each of the four ways.  This seems to indicate that a 
cross-compile is just as good as native compilation, which is 
great because I can cross-compile much faster on a single core of 
my core i5 than natively compiling ldc and the unit tests on the 
dual Cortex-A7 cores of the Cubieboard2 I'm testing on.

The std.string.sformat issue with the phobos tests that I 
mentioned earlier was in a static ctor for std.net.curl.  Once I 
removed that module from the test runner, I got 4 phobos modules' 
tests to pass, 10 modules assert in a test somewhere, 44 seg 
fault, and 8 say they "Aborted," so I'm 4/69 on the phobos unit 
tests right now (I got std.traits to compile with a small fix).  
Is that about what you guys got when you ran the phobos tests on 
ARM before?

I can't say if EH is the main issue or if there are other porting 
issues, as I haven't started looking into the details yet.
Sep 02 2014
next sibling parent David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On 2 Sep 2014, at 11:44, Joakim via digitalmars-d-ldc wrote:

 On Saturday, 30 August 2014 at 21:58:18 UTC, David Nadlinger via 
 digitalmars-d-ldc wrote:

 When I last tried (which was a _long_ time ago), there were still 
 some random crashes in the unit tests that looked like they were 
 caused by an error during unwinding.


 If you mean random in the sense that the same test will sometimes pass 
 and sometimes crash, I haven't seen that.


Sorry, I was a bit imprecise. I meant "random" as in "it failed in some 
of the tests, but I didn't see an obvious similarity without actually 
starting to track down the issue".

Best,
David
Sep 02 2014
prev sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Tuesday, 2 September 2014 at 09:44:29 UTC, Joakim wrote:

 The std.string.sformat issue with the phobos tests that I 
 mentioned earlier was in a static ctor for std.net.curl.  Once 
 I removed that module from the test runner, I got 4 phobos 
 modules' tests to pass, 10 modules assert in a test somewhere, 
 44 seg fault, and 8 say they "Aborted," so I'm 4/69 on the 
 phobos unit tests right now (I got std.traits to compile with a 
 small fix).  Is that about what you guys got when you ran the 
 phobos tests on ARM before?

 I can't say if EH is the main issue or if there are other 
 porting issues, as I haven't started looking into the details 
 yet.


I just tried cross-compiling to ARM with the merge-2.066 branch 
and llvm 3.5 and the latter seems to make a bunch of seg faults 
go away. :) rt.minfo passes its tests now, but core.time asserts 
and so does core.internal.convert still.  As for phobos, 3 
modules pass, 46 modules assert- 41 of which assert in one test 
in std.format, not sure why other modules are running tests for 
std.format- only 9 segfault, and 10 are "Aborted," so I'm down to 
3/69 now, but hopefully much easier to fix with less segfaults.

I didn't get this improvement with merge-2.066 and llvm 3.4, so 
it's definitely llvm 3.5 that made the difference, not sure why.
Sep 11 2014
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Thursday, 11 September 2014 at 21:29:52 UTC, Joakim wrote:

 On Tuesday, 2 September 2014 at 09:44:29 UTC, Joakim wrote:

 The std.string.sformat issue with the phobos tests that I 
 mentioned earlier was in a static ctor for std.net.curl.  Once 
 I removed that module from the test runner, I got 4 phobos 
 modules' tests to pass, 10 modules assert in a test somewhere, 
 44 seg fault, and 8 say they "Aborted," so I'm 4/69 on the 
 phobos unit tests right now (I got std.traits to compile with 
 a small fix).  Is that about what you guys got when you ran 
 the phobos tests on ARM before?

 I can't say if EH is the main issue or if there are other 
 porting issues, as I haven't started looking into the details 
 yet.


 I just tried cross-compiling to ARM with the merge-2.066 branch 
 and llvm 3.5 and the latter seems to make a bunch of seg faults 
 go away. :) rt.minfo passes its tests now, but core.time 
 asserts and so does core.internal.convert still.  As for 
 phobos, 3 modules pass, 46 modules assert- 41 of which assert 
 in one test in std.format, not sure why other modules are 
 running tests for std.format- only 9 segfault, and 10 are 
 "Aborted," so I'm down to 3/69 now, but hopefully much easier 
 to fix with less segfaults.

 I didn't get this improvement with merge-2.066 and llvm 3.4, so 
 it's definitely llvm 3.5 that made the difference, not sure why.


More good news, the sieve.d sample file from dmd's repo now not 
only compiles fine against phobos but doesn't spit out junk 
output anymore, ie it works.  I wish all ldc problems could just 
be solved by an llvm upgrade like this. ;)
Sep 11 2014
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Thursday, 11 September 2014 at 21:44:29 UTC, Joakim wrote:

 On Thursday, 11 September 2014 at 21:29:52 UTC, Joakim wrote:

 On Tuesday, 2 September 2014 at 09:44:29 UTC, Joakim wrote:

 The std.string.sformat issue with the phobos tests that I 
 mentioned earlier was in a static ctor for std.net.curl.  
 Once I removed that module from the test runner, I got 4 
 phobos modules' tests to pass, 10 modules assert in a test 
 somewhere, 44 seg fault, and 8 say they "Aborted," so I'm 
 4/69 on the phobos unit tests right now (I got std.traits to 
 compile with a small fix).  Is that about what you guys got 
 when you ran the phobos tests on ARM before?

 I can't say if EH is the main issue or if there are other 
 porting issues, as I haven't started looking into the details 
 yet.


 I just tried cross-compiling to ARM with the merge-2.066 
 branch and llvm 3.5 and the latter seems to make a bunch of 
 seg faults go away. :) rt.minfo passes its tests now, but 
 core.time asserts and so does core.internal.convert still.  As 
 for phobos, 3 modules pass, 46 modules assert- 41 of which 
 assert in one test in std.format, not sure why other modules 
 are running tests for std.format- only 9 segfault, and 10 are 
 "Aborted," so I'm down to 3/69 now, but hopefully much easier 
 to fix with less segfaults.

 I didn't get this improvement with merge-2.066 and llvm 3.4, 
 so it's definitely llvm 3.5 that made the difference, not sure 
 why.


 More good news, the sieve.d sample file from dmd's repo now not 
 only compiles fine against phobos but doesn't spit out junk 
 output anymore, ie it works.  I wish all ldc problems could 
 just be solved by an llvm upgrade like this. ;)


Yikes, spoke too soon, it prints out the first line and then 
segfaults.  I guess this is an improvement over junk output.
Sep 11 2014
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Thursday, 11 September 2014 at 21:48:43 UTC, Joakim wrote:

 On Thursday, 11 September 2014 at 21:44:29 UTC, Joakim wrote:

 More good news, the sieve.d sample file from dmd's repo now 
 not only compiles fine against phobos but doesn't spit out 
 junk output anymore, ie it works.  I wish all ldc problems 
 could just be solved by an llvm upgrade like this. ;)


 Yikes, spoke too soon, it prints out the first line and then 
 segfaults.  I guess this is an improvement over junk output.


Got the segfault in the sieve program to go away by changing the 
default calling convention for all linkage types in gen/abi.cpp 
to C, just as Kai did on PPC64.  I don't get any "Aborted" tests 
now either.

One issue cropping up in std.format appears to be with structs 
that use alias this for a member, specifically these two:

https://github.com/D-Programming-Language/phobos/blob/master/std/format.d#L1307
https://github.com/D-Programming-Language/phobos/blob/master/std/format.d#L1748

The first one returns false, the second one returns a junk number 
for the imaginary component of the complex number.  Not sure why 
it fails for some structs that use alias this and not others, 
going to look into it.

Another issue is that the dwarf output for debugging might be 
corrupted somehow.  If I compile sieve.d and have it run fine 
against non-debug druntime/phobos, it then segfaults in different 
places if I link it against debug druntime or phobos, which are 
simply compiled with the -g flag.

Finally, many modules still claim that they assert in a test in 
std.format, when std.format itself says that test passes, weird.
Sep 15 2014
parent "Joakim" <dlang joakim.fea.st> writes:
On Monday, 15 September 2014 at 07:33:26 UTC, Joakim wrote:

 Got the segfault in the sieve program to go away by changing 
 the default calling convention for all linkage types in 
 gen/abi.cpp to C, just as Kai did on PPC64.  I don't get any 
 "Aborted" tests now either.

 One issue cropping up in std.format appears to be with structs 
 that use alias this for a member, specifically these two:

 https://github.com/D-Programming-Language/phobos/blob/master/std/format.d#L1307
 https://github.com/D-Programming-Language/phobos/blob/master/std/format.d#L1748

 The first one returns false, the second one returns a junk 
 number for the imaginary component of the complex number.  Not 
 sure why it fails for some structs that use alias this and not 
 others, going to look into it.


Hey Kai, I see that you just mentioned that you're still trying 
ldc on linux/ARM.  I never got an answer to my question before: 
how many tests pass for you when running on linux/ARM?  I've 
detailed my results here: most of druntime passes while most of 
phobos doesn't.


 Another issue is that the dwarf output for debugging might be 
 corrupted somehow.  If I compile sieve.d and have it run fine 
 against non-debug druntime/phobos, it then segfaults in 
 different places if I link it against debug druntime or phobos, 
 which are simply compiled with the -g flag.


I figured out what the problem was with debug: it's that 
codeGenOptLevel() in gen/optimizer.cpp turns off all 
optimizations when generating debug symbols is turned on.  As we 
both noted previously that ldc is generating buggy code for -O0 
with ARM, the problem is with the generated code, not debug 
output.  If I patch that ldc function so that debug output can be 
used with different optimization levels, I can debug again on 
linux/ARM if I use an optimization level of -O1 or higher, though 
I haven't tested it extensively.

I had tried using different optimization levels with debug 
before, but didn't know ldc was silently turning it off till now. 
  I notice that clang doesn't seem to turn optimization off for 
debug and that the ldc patch that turned optimization off is more 
than five years old: perhaps it's not necessary?
Sep 29 2014
prev sibling parent "Kai Nacke" <kai redstar.de> writes:
Hi Joe!

On Sunday, 13 July 2014 at 10:16:36 UTC, Joseph Rushton Wakeling 
wrote:

 I decided to start trying out the ARM embedded programming 
 ideas in Adam Ruppe's D Cookbook.  Speaking as a complete 
 newcomer to this area of programming, I was wondering: although 
 Adam advises using GDC in his tutorials, would it be possible 
 to use LDC instead -- and if so, what to use in place of the 
 calls to arm-gdcproject-linux-gnueabi-gdc, 
 arm-gdcproject-linux-gnueabi-as, 
 arm-gdcproject-linux-gnueabi-ld, and 
 arm-gdcproject-linux-gnueabi-objcopy ... ?

 I'm building LDC on top of llvm 3.4, so is the ARM support here 
 adequate in any case?


You can build LDC on an ARM system without problem. Most stuff 
works out of the box. Prominent exceptions are exception handling 
and some std.math stuff. Most annoying: there is a bug(?) in 
dso_ctor()/dso_dtor() which prevents compiling with -O0. If you 
use -O1 or higher everything works.

More likely you want to cross compile to ARM. The problem here is 
floating point support as ARM does not have a real (80-bit) 
floating point type. Currently, you can't change this without 
recompiling LDC. (Change real_t to double and use the double 
constants instead of the long double ones.) This is the reason 
why the binary distributions do not contain an ARM backend.

llvm 3.4 is ok for code generation. As far as I remember wrong 
relocations are generated for debug info of TLS variables.

Just give it a try. :-)

Regards,
Kai
Jul 14 2014