D.gnu - Undefined Reference to volatileLoad/Store Instrinsics
- Mike (91/91) Jul 18 2017 I'm currently try to replace my old volatileLoad/Store functions
- Iain Buclaw via D.gnu (10/18) Jul 18 2017 Yes, the signature it looks for is FNbNiNf for volatileLoad and
- Mike (9/13) Jul 18 2017 Thanks, and sorry for the foolish mistake. I'm getting a working
I'm currently try to replace my old volatileLoad/Store functions that utilized a `shared` bug as an alternative to `volatile`. The used to look like this: inline T volatileLoad(T)(T* a) { asm { "" ::: "memory"; }; return *cast(shared T*)a; } inline void volatileStore(T)(T* a, in T v) { asm { "" ::: "memory"; }; *cast(shared T*)a = v; } Now I'm implementing them like this: private T volatileLoad(T)(T* a) { static import core.bitop; static if (T.sizeof == 1) { return cast(T)core.bitop.volatileLoad(cast(ubyte*)a); } else static if (T.sizeof == 2) { return cast(T)core.bitop.volatileLoad(cast(ushort*)a); } else { return cast(T)core.bitop.volatileLoad(cast(uint*)a); } } private void volatileStore(T)(T* a, in T v) { static import core.bitop; static if (T.sizeof == 1) { core.bitop.volatileStore(cast(ubyte*)a, cast(ubyte)v); } else static if (T.sizeof == 2) { core.bitop.volatileStore(cast(ushort*)a, cast(ushort)v); } else { core.bitop.volatileStore(cast(uint*)a, cast(uint)v); } } I have the volatileLoad/Store functions declared in a core.bitop file like so: module core.bitop; ubyte volatileLoad(ubyte * ptr); ushort volatileLoad(ushort* ptr); uint volatileLoad(uint * ptr); ulong volatileLoad(ulong * ptr); void volatileStore(ubyte * ptr, ubyte value); void volatileStore(ushort* ptr, ushort value); void volatileStore(uint * ptr, uint value); void volatileStore(ulong * ptr, ulong value); However, when I compile, the intrinsics don't appear to be emitted and I get an undefined reference at link-time. core/bitop.d is located in source/runtime which is imported with the switch -Isource/runtime. arm-none-eabi-gdc -c -O0 -nophoboslib -nostdinc -nodefaultlibs -nostdlib -fno-emit-moduleinfo -mthumb -mcpu=cortex-m4 -Isource/runtime -fno-bounds-check -fno-invariants -fno-in -fno-out -ffunction-sections -fdata-sections source/gcc/attribute.d source/board/lcd.d source/board/ILI9341.d source/board/package.d source/board/statusLED.d source/board/ltdc.d source/board/random.d source/board/spi5.d source/stm32f42/nvic.d source/stm32f42/gpio.d source/stm32f42/flash.d source/stm32f42/scb.d source/stm32f42/spi.d source/stm32f42/pwr.d source/stm32f42/ltdc.d source/stm32f42/trace.d source/stm32f42/rcc.d source/stm32f42/bus.d source/stm32f42/rng.d source/stm32f42/dma2d.d source/stm32f42/mmio.d source/main.d -o binary/firmware.o arm-none-eabi-ld binary/firmware.o -Tlinker/linker.ld --gc-sections -o binary/firmware binary/firmware.o: In function `_D8stm32f424mmio21__T13volatileStoreTbZ13volatileStoreFPbxbZv': attribute.d:(.text._D8stm32f424mmio21__T13volatileStoreTbZ13volatileStoreFPbxbZv[_D8stm32f424mmio21__T13volatileStoreTbZ13volatile toreFPbxbZv]+0x12): undefined reference to `_D4core5bitop13volatileStoreFPhhZv' Analyzing the object file I see this: arm-none-eabi-nm binary/fimrware.o U _D4core5bitop12volatileLoadFPhZh U _D4core5bitop12volatileLoadFPkZk U _D4core5bitop12volatileLoadFPtZt U _D4core5bitop13volatileStoreFPhhZv U _D4core5bitop13volatileStoreFPkkZv U _D4core5bitop13volatileStoreFPttZv Am I doing something wrong? Thanks, Mike
Jul 18 2017
On 18 July 2017 at 22:41, Mike via D.gnu <d.gnu puremagic.com> wrote:Analyzing the object file I see this: arm-none-eabi-nm binary/fimrware.o U _D4core5bitop12volatileLoadFPhZh U _D4core5bitop12volatileLoadFPkZk U _D4core5bitop12volatileLoadFPtZt U _D4core5bitop13volatileStoreFPhhZv U _D4core5bitop13volatileStoreFPkkZv U _D4core5bitop13volatileStoreFPttZv Am I doing something wrong?Yes, the signature it looks for is FNbNiNf for volatileLoad and FNbNiNf for volatileStore. That is nothrow, nogc and safe attributes respectively. Just after module core.bitop; line, add: nothrow: safe: nogc: Regards Iain.
Jul 18 2017
On Tuesday, 18 July 2017 at 20:54:26 UTC, Iain Buclaw wrote:Just after module core.bitop; line, add: nothrow: safe: nogc:Thanks, and sorry for the foolish mistake. I'm getting a working binary now. Well, at least my status LED is blinking and I see my LCD screen trying to do something, though not the random rectangles I was expecting. I suspect it's just a matter of debugging my hardware initialization procedures now. I hope I'll have something to show soon, though I may need to obtain some new hardware. Mike
Jul 18 2017