A incorrect ABI is used by llvm on the riscv64gc-unknown-none-elf target. The ABI used should be lp64d. I've included a minimum working example of this here.
Expected behavior:
cargo build --target riscv64gc-unknown-none-elf --lib
would produce a library with double float ABI due to the +d extension. What is produced is a library with a single float ABI. The ABI used can be checked by looking at the ELF header:
readelf -h target/riscv64gc-unknown-none-elf/debug/librust_uland.a
This gives back:
...
Flags: 0x1, RVC, soft-float ABI
...
I'm expecting:
...
Flags: 0x1, RVC, double-float ABI
...
Note that the riscv64-unknown-linux-gnu target uses the lp64d ABI as expected. Note that it's actually using the wrong ABI (not just setting bits incorrectly in the header). I'm trying to link to a C library that is compiled with the d extension and this fails during linking due to the differing ABIs in use.
A incorrect ABI is used by llvm on the
riscv64gc-unknown-none-elftarget. The ABI used should belp64d. I've included a minimum working example of this here.Expected behavior:
would produce a library with double float ABI due to the
+dextension. What is produced is a library with a single float ABI. The ABI used can be checked by looking at the ELF header:This gives back:
I'm expecting:
Note that the
riscv64-unknown-linux-gnutarget uses thelp64dABI as expected. Note that it's actually using the wrong ABI (not just setting bits incorrectly in the header). I'm trying to link to a C library that is compiled with the d extension and this fails during linking due to the differing ABIs in use.