www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Embedded Systems (STM32) LDC Absolute minimal runtime

reply Dan Walmsley <dan walms.co.uk> writes:
Hi guys,

    I run an open source project developing a modern cross 
platform IDE for embedded systems, 
https://github.com/VitalElement/avalonStudio (perhaps the IDE 
could complement D as I have not found many just works out the 
box solutions for D yet.)

    I have begun to integrate the LDC compiler and would also like 
to attempt to use D in an upcoming embedded project I have.

I have played around with the betterC flag and it looks 
promising. I would also like to have use of classes, however as 
soon as I try to use a class I get many link errors. see below:

The  undefined reference to `_d_dso_registry' comes from removing 
the -betterC flag.

I understand these other symbols would be provided by object.d, 
however I am unable to find an object.d that will compile on LDC, 
and ideally a minimal implementation.

Can anyone help?


C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function 
`_D4main9TestClass3SumMFZi':
C:\dev\repos\STM32DBlinky\Blinky/main.d:9: undefined reference to 
`_D9invariant12_d_invariantFC6ObjectZv'
C:\dev\repos\STM32DBlinky\Blinky/main.d:9: undefined reference to 
`_d_assert_msg'
C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function 
`ldc.register_dso':
C:\dev\repos\STM32DBlinky\Blinky\main.d:(.text.ldc.register_dso+0x60):
undefined reference to `_d_dso_registry'
C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o:(.data.rel.ro._D4main9TestClass6__vtblZ[_D4main9Test
lass6__vtblZ]+0x4): undefined reference to `_D6object6Object8toStringMFZAya'
C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o:(.data.rel.ro._D4main9TestClass6__vtblZ[_D4main9Test
lass6__vtblZ]+0x8): undefined reference to `_D6object6Object6toHashMFNbNeZk'
C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o:(.data.rel.ro._D4main9TestClass6__vtblZ[_D4main9Test
lass6__vtblZ]+0xc): undefined reference to `_D6object6Object5opCmpMFC6ObjectZi'
C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o:(.data.rel.ro._D4main9TestClass6__vtblZ[_D4main9TestC
ass6__vtblZ]+0x10): undefined reference to
`_D6object6Object8opEqualsMFC6ObjectZb'
C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o:(.data._D4main9TestClass7__ClassZ[_D4main9TestC
ass7__ClassZ]+0x0): undefined reference to `_D14TypeInfo_Class6__vtblZ'
C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o:(.data._D4main9TestClass7__ClassZ[_D4main9TestCl
ss7__ClassZ]+0x28): undefined reference to `_D6Object7__ClassZ'
Jun 19 2017
next sibling parent Mike <none none.com> writes:
On Monday, 19 June 2017 at 10:24:29 UTC, Dan Walmsley wrote:


 I have played around with the betterC flag and it looks 
 promising. I would also like to have use of classes, however as 
 soon as I try to use a class I get many link errors. see below:


It is my understanding that the DMD -betterC switch currently 
only disables generating ModuleInfo.  Walter's recent pull 
request 
(http://forum.dlang.org/post/oi9v2q$23ms$1 digitalmars.com) makes 
it do a little more.

It is also my understanding the -betterC is just an idea at the 
moment, and what it should do has not yet been defined.


 The  undefined reference to `_d_dso_registry' comes from 
 removing the -betterC flag.

 I understand these other symbols would be provided by object.d, 
 however I am unable to find an object.d that will compile on 
 LDC, and ideally a minimal implementation.


The most minimal implementation I'm aware of is this: 
https://wiki.dlang.org/Minimal_semihosted_ARM_Cortex-M_%22Hello_World%22

If you're targeting STM32, you may also be interested in this: 
https://github.com/JinShil/stm32f42_discovery_demo

I haven't tested either of those in quite some time, so I doubt 
the will compile out of the box.  But basically, what you need is 
a minimal runtime implementation that implements the features of 
D that your code is using, and unfortunately, some that your code 
isn't using but is required by the compiler just to get a build.


 C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function 
 `_D4main9TestClass3SumMFZi':
 C:\dev\repos\STM32DBlinky\Blinky/main.d:9: undefined reference 
 to `_D9invariant12_d_invariantFC6ObjectZv'
 C:\dev\repos\STM32DBlinky\Blinky/main.d:9: undefined reference 
 to `_d_assert_msg'
 C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function 
 `ldc.register_dso':
 C:\dev\repos\STM32DBlinky\Blinky\main.d:(.text.ldc.register_dso+0x60):
undefined reference to `_d_dso_registry'
 C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o:(.data.rel.ro._D4main9TestClass6__vtblZ[_D4main9Test
lass6__vtblZ]+0x4): undefined reference to `_D6object6Object8toStringMFZAya'
 C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o:(.data.rel.ro._D4main9TestClass6__vtblZ[_D4main9Test
lass6__vtblZ]+0x8): undefined reference to `_D6object6Object6toHashMFNbNeZk'
 C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o:(.data.rel.ro._D4main9TestClass6__vtblZ[_D4main9Test
lass6__vtblZ]+0xc): undefined reference to `_D6object6Object5opCmpMFC6ObjectZi'
 C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o:(.data.rel.ro._D4main9TestClass6__vtblZ[_D4main9TestC
ass6__vtblZ]+0x10): undefined reference to
`_D6object6Object8opEqualsMFC6ObjectZb'
 C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o:(.data._D4main9TestClass7__ClassZ[_D4main9TestC
ass7__ClassZ]+0x0): undefined reference to `_D14TypeInfo_Class6__vtblZ'
 C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o:(.data._D4main9TestClass7__ClassZ[_D4main9TestCl
ss7__ClassZ]+0x28): undefined reference to `_D6Object7__ClassZ'


`_d_assert_msg` and `_d_dso_registry` and those symbols with 
`_d_invariant` in them look like missing druntime 
implementations.  You can see an old and unmaintained list of 
such "runtime hooks" here: https://wiki.dlang.org/Runtime_Hooks.  
Each compiler (DMD, LDC, and GDC) have their own druntime 
implementation, unfortunately.  LDC's implementation is here: 
https://github.com/ldc-developers/druntime

I suspect the `.data.re.ro.*` symbols are the result of an error 
in your linker script.  That is you haven't added that `.data` 
section to your linker script, so the symbols aren't being 
populated.  I'd have to see your linker script and source code 
before I spend to much mental energy on it, though.

No compiler that I'm aware has a druntime implementation for the 
ARM Cortex-M architecture, so the onus is on you to build 
implement whatever features the toolchain is complaining about.

Mike
Jun 20 2017
prev sibling next sibling parent Kagamin <spam here.lot> writes:
I believe you can do without any runtime at all, but it's a 
tradeoff, see also 
https://forum.dlang.org/post/tmofjecvnqdthvetezfp forum.dlang.org
Jun 20 2017
prev sibling parent reply Cora Dias <CoraDias protonmail.com> writes:
Hi...i am a new user here. As per my observation as suggested 
above you need a minimal runtime implementation that implements 
the features of D that your code is using, some that your code is 
not using but is required by the compiler just to get a build.
Apr 05 2018
parent Mike Franklin <slavo5150 yahoo.com> writes:
On Thursday, 5 April 2018 at 15:58:28 UTC, Cora Dias wrote:

 Hi...i am a new user here.


Welcome!


 As per my observation as suggested above you need a minimal 
 runtime implementation that implements the features of D that 
 your code is using, some that your code is not using but is 
 required by the compiler just to get a build.


Yeah, so D can be both a systems programming language and an 
applications programming language, and it's even convenient 
enough to use a scripting language :-)  But that means that it 
has both high level and low level features.

If you want to do bare-metal programming on the STM32 (or any 
resource-constrained micrcontroller), you may not want or need 
things like the garbage collector, runtime type information, etc. 
(though with something like the STM32F7, it may be the right 
choice). To do the low-level stuff, you just need the fundamental 
compiler facilities, and not much, if anything, from the runtime. 
  So, you have a few options:

1) The -betterC switch - This switch allows you to use D like C.  
No classes, No runtime-type information, no exceptions, but you 
still get the compiler facilities like templates, mixins, etc. 
that aren't found in C.  Thus it is a "better C".  See 
https://dlang.org/spec/betterc.html and 
https://dlang.org/blog/category/betterc/ for lots of information 
about that.

I am, personally, not a fan of betterC, and affectionately call 
it worseD.  IMO, if the compiler would just be fixed to reduce 
coupling to the runtime (as was done recently in 2.079.0) betterC 
would not be needed.

2) A v2.079.0 compliant compiler - 2.079.0 did some long overdue 
decoupling of the compiler from the runtime so you no longer get 
compiler errors for missing features that your code doesn't even 
make use of.  See 
https://dlang.org/changelog/2.079.0.html#minimal_runtime for more 
information about that.

3) A pre-2.079.0 version of a compiler with useless stubs to get 
the compiler to shut up and generate your binary.  Trying to make 
a minimal runtime with the current LDC release is fraught with 
problems: (1) https://github.com/ldc-developers/ldc/issues/781 
(2) https://github.com/ldc-developers/ldc/issues/552  GDC is much 
better, but still requires a few useless stubs to get a build 
(e.g. 
https://github.com/JinShil/stm32f42_discovery_demo/blob/master/source/runtime/object.d)

LDC is currently working on adding the 2.079.0 features:  
https://github.com/ldc-developers/ldc/pull/2641  I hope it will 
be in the next LDC release.  When that's done it will be a much 
better competitor with GDC (and may even surpass it) when it 
comes to ARM Cortex-M programming in D.  I'm currently trying to 
find a way to contribute to GDC to accelerate its progress, but I 
have a lot to learn.

A few resource which you may find interesting:
https://bitbucket.org/timosi/minlibd - probably the most complete 
port of the D runtime to the ARM Cortex-M platform.  I think it's 
only compatible with GDC at the moment though.

https://github.com/JinShil/stm32f42_discovery_demo - A proof of 
concept illustrating the bare-metal programming ARM Cortex-M 
microcontrollers without the need for -betterC, opting for 
minimal runtime instead, is feasible.

https://forum.dlang.org/post/qjowkuwstewnmdunepiq forum.dlang.org,
https://theartofmachinery.com/2018/04/02/inheritance_and_polymorphism.html - A
very cool way of using D's mixin features to simulate classes without the D
runtime.

I hope that will give you some of what you were looking for.

Mike
Apr 05 2018