www.digitalmars.com         C & C++   DMDScript  

D.gnu - Undefined Reference to volatileLoad/Store Instrinsics

reply Mike <none none.com> writes:
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
parent reply "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:
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
parent Mike <none none.com> writes:
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