LDC 1.2.0-beta1 has been released!

[Joakim via digitalmars-d-ldc]

On Friday, 24 March 2017 at 18:36:32 UTC, Radu wrote:
> On Friday, 24 March 2017 at 17:22:31 UTC, Joakim wrote:
>> On Friday, 24 March 2017 at 08:11:15 UTC, Radu wrote:
>>> On Friday, 24 March 2017 at 07:30:58 UTC, Radu wrote:
>>>> On Friday, 24 March 2017 at 06:19:34 UTC, Joakim wrote:
>>>>> [...]
>>>>
>>>> I tried a couple of things
>>>>
>>>> ldc2 -mtriple=arm-none-linux-gnueabi 
>>>> -gcc=arm-linux-gnueabi-gcc
>>>>
>>>> [...]
>>>
>>> Did a small test in C++ using the gcc cross compiler and 
>>> exceptions are working with the same ABI and cpu name and 
>>> arch as the ones I got with ldc. So eabi version is not an 
>>> issue here.
>>
>> OK, looking up that CPU now, it's an old ARMv5 core, whereas 
>> we've tested on ARMv6 at best.  If you want to use ldc for 
>> that, you may need to help port ldc/druntime to those older 
>> embedded cores.
>
> Yes, I would very much like to get ldc to run on those cores - 
> they are used on a lot of industrial controllers. My goal is to 
> put D based software on those controllers.
>
> Good news is that some basic stuff works so there is some 
> incentive to try to get the rest of the missing parts running.
>
> Please let me know how I can help, mind that I'm not versed in 
> LLVM/LDC nor ARM low-level stuff - but if instructed on 
> where/how to do stuff I can hack around my way.

Take a look at my instructions on how to get going for Android 
here:

http://wiki.dlang.org/Build_LDC_for_Android

Ignore the section on modifying and compiling llvm if your 
platform has native Thread-Local Storage (TLS).  If so, you can 
just use a prebuilt llvm, assuming it comes with the ARM backend, 
as llvm usually does.

Here is my small patch for cross-compiling with ldc 1.2, which I 
just posted online:

https://gist.github.com/joakim-noah/ac35132fd2cd0283c45961312d91e214

Use it instead of the larger one linked from the wiki, after 
modifying it for your platform.  In particular, you probably 
won't need the tgmath exclusion, set the C compiler and other 
flags as needed for your platform, and you only need look at the 
stuff for the test-runner custom target, as the test-runner-apk 
target is particular to Android.

Also, you will need to set the llvm triple for cross-compiling, 
by modifying D_FLAGS, ie change "-w" to 
"-w;-mtriple=armv5tej-none-linux-gnueabi;-float-abi=soft" and 
whatever other flags you need.  I didn't need to do this because 
I changed the default target of my custom llvm to Android/ARM, 
but you need it if using a standard llvm.

You won't need to modify druntime and phobos with my Android 
patches, so follow the rest of the wiki instructions to build a 
test runner _without_ applying my stdlib patches, and see what 
modules' tests pass with the resulting test runner.  A lot of 
modules don't deal with exception-handling, particularly in 
druntime, so you can see the extent of the platform support this 
way.  Compile without any optimizations at first, ie change -O3 
to -O0, as those might be screwing things up.

If the problem is really only exception-handling, compare the 
definitions in the druntime/src/ldc/eh modules to those for your 
platform.  It could be something as simple as those basic structs 
are defined differently.  If not, turn on all the debug output 
there, which you already found, and try to step through with a 
debugger and see where it's going wrong.

> Also, I added a bunch of useful details on the bug you posted 
> https://github.com/ldc-developers/ldc/issues/2024

That issue is more about Android and ARMv7, I suggest you open 
your own issue and apprise us of your progress there.