www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - Where is the arm-none-eabi target?

reply IGotD- <nise nise.com> writes:
I'm trying to compile druntime for a custom OS. When I try to 
compile for the target triple -target=arm-none-eabi, the compiler 
does nothing without any error messages and there is no object 
file output at all. However according to this guide.

https://wiki.dlang.org/Minimal_semihosted_ARM_Cortex-M_%22Hello_World%22

it uses the triple thumb-none-linux-eabi, which is kind odd of 
but it might work for that particular case.

The problem is when using thumb-none-linux-eabi, the compiler 
automatically inserts D version identifiers like Posix. There are 
ways around this like putting your desired target sooner in the 
version if-else statements but still for completeness shouldn't 
the non OS target be supported and why aren't there any warning 
messages when using the arm-none-eabi target?
Mar 13
next sibling parent reply kinke <noone nowhere.com> writes:
On Friday, 13 March 2020 at 14:41:03 UTC, IGotD- wrote:
 The problem is when using thumb-none-linux-eabi, the compiler 
 automatically inserts D version identifiers like Posix.
Yes, Linux is a Posix target.
 but still for completeness shouldn't the non OS target be 
 supported
It is and doesn't predefine Posix etc. then; try `-mtriple=thumb--none-eabi` (or `thumb-unknown-eabi` etc.).
 and why aren't there any warning messages when using the 
 arm-none-eabi target?
Probably because it works just fine, at least it does for me with LDC v1.20 on Windows - `ldc2 -c -mtriple=arm-none-eabi hello.d -v && ls -l hello.o`. `-v` shows the expanded triple (3rd line, => arm-none-unknown-eabi).
Mar 13
next sibling parent reply IGotD- <nise nise.com> writes:
On Friday, 13 March 2020 at 17:06:03 UTC, kinke wrote:
 On Friday, 13 March 2020 at 14:41:03 UTC, IGotD- wrote:
 The problem is when using thumb-none-linux-eabi, the compiler 
 automatically inserts D version identifiers like Posix.
Yes, Linux is a Posix target.
 but still for completeness shouldn't the non OS target be 
 supported
It is and doesn't predefine Posix etc. then; try `-mtriple=thumb--none-eabi` (or `thumb-unknown-eabi` etc.).
 and why aren't there any warning messages when using the 
 arm-none-eabi target?
Probably because it works just fine, at least it does for me with LDC v1.20 on Windows - `ldc2 -c -mtriple=arm-none-eabi hello.d -v && ls -l hello.o`. `-v` shows the expanded triple (3rd line, => arm-none-unknown-eabi).
You are right, any other file works with arm-none-eabi. Actually this might be more related to druntime rather than arm-none-eabi. Try. cd ldc/runtime/druntime/src (where your druntime is located). ldc2 -c --output-o -conf= -w -de -dip1000 -mtriple=arm-none-eabi -O3 -release -preview=fieldwise -od=/tmp/objects -op core/atomic.d ls /tmp/objects/core, and there is no atomic.o file. the compiler just gives a warning: Warning: Assuming critical section size = 40 bytes not sure what this is about. change -mtriple to arm-none-linux-eabi and the object file is created. I've tried to find if some identifier is missing because of this but I haven't found any also atomic should only be CPU architecture dependent.
Mar 13
parent reply kinke <noone nowhere.com> writes:
On Friday, 13 March 2020 at 21:47:02 UTC, IGotD- wrote:
 cd ldc/runtime/druntime/src (where your druntime is located).
 ldc2 -c --output-o -conf= -w -de -dip1000 
 -mtriple=arm-none-eabi -O3 -release -preview=fieldwise 
 -od=/tmp/objects -op core/atomic.d
Works fine for me, again with v1.20 on Windows, no warnings wrt. unknown section size (needs OS-specific compiler support for `synchronized`). I can only guess that you are using an older LDC version.
Mar 13
parent reply kinke <noone nowhere.com> writes:
On Friday, 13 March 2020 at 22:11:57 UTC, kinke wrote:
 I can only guess that you are using an older LDC version.
Note that druntime and the compiler are tightly coupled because both depend on each other, so you should always use the corresponding LDC version to compile druntime. I.e., not trying to build our current druntime (branch `ldc`) with LDC v1.20, nor trying to build druntime v1.20/2.090 with older LDC versions. ldc-build-runtime usually handles that for you. - The atomic intrinsics have been reworked recently.
Mar 14
parent IGotD- <nise nise.com> writes:
On Saturday, 14 March 2020 at 12:51:30 UTC, kinke wrote:
 Note that druntime and the compiler are tightly coupled because 
 both depend on each other, so you should always use the 
 corresponding LDC version to compile druntime. I.e., not trying 
 to build our current druntime (branch `ldc`) with LDC v1.20, 
 nor trying to build druntime v1.20/2.090 with older LDC 
 versions. ldc-build-runtime usually handles that for you. - The 
 atomic intrinsics have been reworked recently.
I'm using LDC 1.20.1. I cloned the entire LDC git for my changes in the runtime and the version for druntime in particular is e96b6f2. Date: Tue Feb 25 01:50:21 2020 +0100 Latest tag is ldc-v1.20.0 three commits earlier and I don't find any tag for 1.20.1 so my git might be a bit old.
Mar 14
prev sibling parent reply IGotD- <nise nise.com> writes:
On Friday, 13 March 2020 at 17:06:03 UTC, kinke wrote:
 Probably because it works just fine, at least it does for me 
 with LDC v1.20 on Windows
I just tried with LDC 1.20.1 on Windows, there it compiles the to the object files just as you previously tested. We have a difference between Linux and Windows for the same command line.
Mar 18
parent kinke <noone nowhere.com> writes:
On Wednesday, 18 March 2020 at 12:57:26 UTC, IGotD- wrote:
 On Friday, 13 March 2020 at 17:06:03 UTC, kinke wrote:
 Probably because it works just fine, at least it does for me 
 with LDC v1.20 on Windows
I just tried with LDC 1.20.1 on Windows, there it compiles the to the object files just as you previously tested. We have a difference between Linux and Windows for the same command line.
The difference is that on Windows hosts, we don't have any fallback value for the critical section size for an unknown; the first time it is needed, an error is issued. For Posix hosts, we use the native `pthread_mutex_t` size as fallback value, coupled with a one-time warning issued during initialization. The `-w` in your cmdline aborts on warnings; you can use `-wi` to have them printed but continue. It might be better never to fall back to the native size, not just for consistency across hosts.
Mar 18
prev sibling parent reply dangbinghoo <dangbinghoo gmail.com> writes:
On Friday, 13 March 2020 at 14:41:03 UTC, IGotD- wrote:
 I'm trying to compile druntime for a custom OS. When I try to 
 compile for the target triple -target=arm-none-eabi, the 
 compiler does nothing without any error messages and there is 
 no object file output at all. However according to this guide.

 https://wiki.dlang.org/Minimal_semihosted_ARM_Cortex-M_%22Hello_World%22

 it uses the triple thumb-none-linux-eabi, which is kind odd of 
 but it might work for that particular case.

 The problem is when using thumb-none-linux-eabi, the compiler 
 automatically inserts D version identifiers like Posix. There 
 are ways around this like putting your desired target sooner in 
 the version if-else statements but still for completeness 
 shouldn't the non OS target be supported and why aren't there 
 any warning messages when using the arm-none-eabi target?
IMO, ldc right now will not work without a real OS like windows/linux/macos, as druntime and phobos is built upon with clib. And none-eabi doesn't have the "standard C library". it will only work with arm-none-eabi target when trying to build LDC a "betterC compiler".
Mar 31
parent IGotD- <nise nise.com> writes:
On Tuesday, 31 March 2020 at 09:59:44 UTC, dangbinghoo wrote:
 On Friday, 13 March 2020 at 14:41:03 UTC, IGotD- wrote:

 IMO, ldc right now will not work without a real OS like 
 windows/linux/macos, as druntime and phobos is built upon with 
 clib. And none-eabi doesn't have the "standard C library".

 it will only work with arm-none-eabi target when trying to 
 build LDC a "betterC compiler".
I'm using arm-none-eabi so that the compiler doesn't pre-select any operating system. Then I just use the --d-version option to inject my own verison of my custom OS. This seems to be working
Mar 31