Missing __atomic_load & __atomic_store intrinsics' implementation for esp32c3 (& maybe esp32s2) (IDFGH-5896)

[ivmarkov]

The implementation of atomics here is broken for Rust+LLVM+ESP-IDF+esp32c3 in that it does not define the __atomic_load and __atomic_store intrinsics for esp32c3. By the way, it does not define these for esp32s2 either?

It might be a simple omission, or it might be a misinterpretation of what the compiler (Rust + LLVM at least, not sure for GCC) would generate in terms of atomic libcalls on the Riscv32IMC architecture:

• The compiler WILL generate calls to __atomic_load / __atomic_store even though loads/stores on that architecture are atomic, because - as per this comment - it is not safe to mix CPU-implemented atomicity (load/store) with libcall-implemented atomicity (e.g. CAS). Since CAS is not natively supported on Riscv32IMC, Rust+LLVM in fact does generate calls to __atomic_load / __atomic_store.

Suggested fix: just add

ATOMIC_LOAD(1, uint8_t)
ATOMIC_LOAD(2, uint16_t)
ATOMIC_LOAD(4, uint32_t)

ATOMIC_STORE(1, uint8_t)
ATOMIC_STORE(2, uint16_t)
ATOMIC_STORE(4, uint32_t)

... here.

[ivmarkov]

@igrr ^^^

(Playing with ESP-IDF master in cargo-native build and - to my surprise - got undefined reference to __atomic_load/store_NN from the linker.)

Implementing the suggested fix takes care of the linker errors.

[MabezDev]

Ah yes, so this is because GCC implemented the native load/stores (that are theoretically UB, whether it happens in practice is unknown) but as you know from that link, its not implemented in llvm. I think your fix is correct, and simple to implement.

[ivmarkov]

@igrr The committed fix is not quite correct, because the missing atomics are ONLY implemented when building with clang

However, we need them when the ESP-IDF is built with GCC too, because:

• While the Rust code is (always, for now) built with LLVM
• ... the ESP-IDF can be built with GCC, and even in that build mode, it does have to provide the above atomics, for Rust+LLVM, who is always lowering the load/store (on RiscV) and test-lock-and-set (for esp32s2) to libcalls...