oreboot won't build for riscv64: __atomic_{load,store}_16 are not defined #66240
Comments
jonas-schievink
added
O-riscv
|
Already reported to upstream crate: rust-lang/compiler-builtins#322 |
|
here is the "fix" for oreboot `+.globl __atomic_store_16
+.globl __atomic_load_16
` i.e. fake up no op atomic load and store for 16 bits, b/c the architecture does not support them. You're asking the architecture to do something it can't do ... :-p |
|
sorry about the format, that's what github claims is a code copy/paste?
+.globl __atomic_load_16
.globl _stack_ptr |
|
Copying comment from oreboot/oreboot#183 (comment) |
|
Yeah. This issue comes up every so often, especially more recently. The RISC-V "A" extension only introduces instructions for 32- and 64-bit atomic operations. If you need up-to-32-bit atomic operations (ie, 8-bit or 16-bit atomic operations), then you have to link with LLVM's compiler-rt is a slightly different, and contains both the compiler builtins and the atomic libcalls in the same library, so this issue should arise less once LLVM can switch to compiler-rt for RISC-V. That could happen soon given https://reviews.llvm.org/D68393 has landed. |
|
I was fixed in compiler-builtins crate via rust-lang/compiler-builtins#324. |
This roughly reverts PR rust-lang#66548 Atomic "CAS" are still disabled for targets without the *“A” Standard Extension for Atomic Instructions*. However this extension only adds instructions for operations more complex than simple loads and stores, which are always atomic when aligned. In the [Unprivileged Spec v. 20191213](https://riscv.org/technical/specifications/) section 2.6 *Load and Store Instructions* of chapter 2 *RV32I Base Integer Instruction Set* (emphasis mine): > Even when misaligned loads and stores complete successfully, > these accesses might run extremely slowly depending on the implementation > (e.g., when implemented via an invisible trap). Further-more, whereas > **naturally aligned loads and stores are guaranteed to execute atomically**, > misaligned loads and stores might not, and hence require > additional synchronization to ensure atomicity. Unfortunately PR rust-lang#66548 did not provide much details on the bug that motivated it, but rust-lang#66240 and rust-lang#85736 appear related and happen with targets that do have the A extension.
Re-enable atomic loads and stores for all RISC-V targets This roughly reverts PR rust-lang#66548 Atomic "CAS" are still disabled for targets without the *“A” Standard Extension for Atomic Instructions*. However this extension only adds instructions for operations more complex than simple loads and stores, which are always atomic when aligned. In the [Unprivileged Spec v. 20191213](https://riscv.org/technical/specifications/) section 2.6 *Load and Store Instructions* of chapter 2 *RV32I Base Integer Instruction Set* (emphasis mine): > Even when misaligned loads and stores complete successfully, these accesses might run extremely slowly depending on the implementation (e.g., when implemented via an invisible trap). Further-more, whereas **naturally aligned loads and stores are guaranteed to execute atomically**, misaligned loads and stores might not, and hence require additional synchronization to ensure atomicity. Unfortunately PR rust-lang#66548 did not provide much details on the bug that motivated it, but rust-lang#66240 and rust-lang#85736 appear related and happen with targets that do have the A extension.
|
cc @kito-cheng @michaelmaitland @robin-randhawa-sifive Is this issue still an active concern? |
|
First, the suffix of the GCC atomic builtins is in bytes, not in bits, so And, there is a relatively recently ratified Zacas extension supports 128-bit atomic in RISC-V, but it did not exist then and in any case LLVM generates libcalls when 128-bit atomic intrinsics are used on RISC-V. So, I believe this has been fixed by rust-lang/compiler-builtins#324, which fixed the problem of calling 128-bit atomic intrinsics on unsupported platforms. (I began writing RISC-V-related code later than that fix, but at least I have never seen "undefined symbol" error about atomics when compiling binaries for RISC-V bare-metal/Linux, except for a regression I fixed in #114497.) (Btw, AFAIK there are no ratified 16-bit atomic instructions (AMO,LR/SC) in RISC-V except those related to the recently ratified Zabha extension, but 16-bit load/store are exist, and it is possible to implement 16-bit CAS/RMW using 32-bit atomic instructions, and LLVM actually does so.) |
|
Alright, I'm assuming this has been fixed then. |
We have been building github.com/oreboot/oreboot with rust since last spring. Within the last month, we've hit the problem seen in https://dev.azure.com/azure0427/Oreboot%20Pipeline/_build/results?buildId=338, as well as oreboot/oreboot#183
__atomic_store_16 is undefined, as is __atomic_load_16.
oreboot has been working on riscv hardware (riscv64, sifive hifive board) for several months, so we're not quite sure where to start. I've been looking around for similar problems but nothing quite fits.
Thanks.
The text was updated successfully, but these errors were encountered: