Motivations
Hardware atomics do not work on the s3 and the stock esp32 when emplaced inside PSRAM due to PSRAM/chip hardware limitations / hacks.
- Would you like to implement this feature? [y/n] maybe
Solution
The solution is to use a different target than the upstream xtensa-esp32(s3)-espidf one, which - unlike the upstream one - does not enforce hardware atomics for these chips, but rather - forces LLVM to generate libcalls to atomics implemented in software.
These libcalls are anyway already implemented by ESP-IDF, and are used for all other chips which do not have hardware atomics in the first place (esp32s2, esp32c2, esp32c3).
The one problem is, such a change would never be accepted upstream, as the ESP-IDF sofware atomics are - by necessity - lock-ful, which upstream does not allow, so that Rust atomics can be used as the basis for implementing futexes and stuff, which requires lockless atomics.
However, the "lock-fulness" of the software atomics in ESP-IDF is happening in very corner cases rather than during normal program execution (like a NMI interrupt avalanche and similar).
So it might be that this is the lesser evil, compared to inability to use PSRAM in an ergonomic way.
Therefore, a first step might be to just implement a target that emits atomics as software ones as a JSON one.
Alternatives
The current status quo - "don't place atomics in PSRAM" - ergo - a terrible hidden pitfall, as this cannot be enforced.
Additional context
rust-lang/rust#117305 (comment)
Motivations
Hardware atomics do not work on the s3 and the stock esp32 when emplaced inside PSRAM due to PSRAM/chip hardware limitations / hacks.
Solution
The solution is to use a different target than the upstream
xtensa-esp32(s3)-espidfone, which - unlike the upstream one - does not enforce hardware atomics for these chips, but rather - forces LLVM to generate libcalls to atomics implemented in software.These libcalls are anyway already implemented by ESP-IDF, and are used for all other chips which do not have hardware atomics in the first place (esp32s2, esp32c2, esp32c3).
The one problem is, such a change would never be accepted upstream, as the ESP-IDF sofware atomics are - by necessity - lock-ful, which upstream does not allow, so that Rust atomics can be used as the basis for implementing futexes and stuff, which requires lockless atomics.
However, the "lock-fulness" of the software atomics in ESP-IDF is happening in very corner cases rather than during normal program execution (like a NMI interrupt avalanche and similar).
So it might be that this is the lesser evil, compared to inability to use PSRAM in an ergonomic way.
Therefore, a first step might be to just implement a target that emits atomics as software ones as a JSON one.
Alternatives
The current status quo - "don't place atomics in PSRAM" - ergo - a terrible hidden pitfall, as this cannot be enforced.
Additional context
rust-lang/rust#117305 (comment)