Comments (15)
where the kernel provides a __kuser_cmpxchg function which can be called at address 0xffff0fc0.
For others targets that need a lock based solution, it seems that we could use a lang item. Perhaps add a "user"
option to max_atomic_width
and have the compiler request a lang item for each intrinsic that LLVM needs. Ideally, the compiler should only ask for the intrinsics that will actually be used in the target programs and not all of them at once.
This certainly needs a proper RFC.
from compiler-builtins.
Their implementation would likely use locking by temporarily disabling the interrupts.
There's a problem with this implementation. This would always work with Cortex-M0 devices but Cortex-M0+ processors have this concept of privileged vs unprivileged execution mode. The instruction that disables/enables interrupts doesn't work when the processor is in unprivileged mode. That means that atomics based on enabling/disabling interrupts won't work (won't be actually atomic) if the processor is in unprivileged mode.
cc @whitequark
from compiler-builtins.
The libs team decided awhile back that when adding the various atomic types that if the platform didn't have support for them the standard library wouldn't export them. That is, we always felt pretty uncomfortable falling back to compiler-rt intrinsics to implement critical operations like atomics which can have serious effects on runtime functionality.
That being said, however, if you do want the fallbacks as you've verified they work for you, then we don't have a great story for that. We perhaps definitely need to improve there!
from compiler-builtins.
@alexcrichton My understanding of the lib team decision was that falling back to compiler-rt intrinsics was bad because those don't necessarily guarantee lock freedom. This means that they can result in incorrect behavior if mixed with signals for example.
However if compiler-rt can provide atomic operations while still guaranteeing lock freedom then IMO this should be acceptable. One specific case I have in mind is atomic support for pre-ARMv6 Linux, where the kernel provides a __kuser_cmpxchg
function which can be called at address 0xffff0fc0.
from compiler-builtins.
I don't think that lock-based solutions should be provided by the standard library. I have a crate which provides a generic Atomic<T>
type which falls back to a spinlock if the target doesn't support the necessary atomic operations for the given object size.
from compiler-builtins.
we could use a lang item
Or this could be a stopgap perma-unstable solution until we come up with a better one. It depends on how much demand there is for this.
An alternative for the actual problem at hand, people want to cross compile alloc / collections for the thumbv6m target, is to add an option to the alloc crate to not depend on any atomic; that would imply getting replacing the current OOM handling code with something else (I don't know with what tough)
from compiler-builtins.
Yes, what I want to do is compile liballoc for Cortex-M0 (a Qualcomm/NXP/Freescale Kinetis KE06Z).
from compiler-builtins.
@japaric It's not just the OOM handling code, liballoc also contains the implementation of Arc
.
from compiler-builtins.
@Amanieu yeah, Arc
can cfg-ed away too. People mostly to use the alloc interface to get Box
and Vec
working on this thumbv6m target.
from compiler-builtins.
I was curious, so I did a quick check with arm-none-eabi-gcc 5.2 and the _Atomic int type.
#include <stdatomic.h>
_Atomic int g_lock = 0;
void test_function(void)
{
g_lock++;
}
With a Cortex-M4 target, gcc emits ldrex
/strex
instructions. With a Cortex-M0 target it emits a call to __atomic_compare_exchange_4
. The cortex-m0plus and cortex-m0 targets produce identical code in this case. Interestingly if I try arm-linux-gnu-gcc it refuses to compile for M0, M0+ or M1, but does for M3 and M4. Perhaps because it can't turn interrupts off in user code.
from compiler-builtins.
@japaric my preference here would be to just add the appropriate cfg to the liballoc crate for now to get it to compile out Arc
if atomics don't exist. The standard library wouldn't work yet but we could in theory update it eventually.
from compiler-builtins.
@alexcrichton Alright. Sent rust-lang/rust#37492 implementing this approach. alloc and collections can be compiled for the thumbv6m with that change.
from compiler-builtins.
This is quite an old bug at this point and I believe it's been sorted out, so closing.
from compiler-builtins.
See https://reviews.llvm.org/D61052 for a related discussion.
from compiler-builtins.
Digging this one up. I also need Arc
on a Cortex-M0 microcontroller, to implement basic functionality above FreeRTOS.
What if we'd make the Arc implementation generic over AtomicUSize that would default to core::sync::AtomicUSize
on platforms that implement it, but would alloc a user to create Arc<T, MyAtomicUSize>
if he can provide a way to safely implement the necessary operations?
from compiler-builtins.
Related Issues (20)
- The "mangled-names" feature removes intrinsics from compiler_builtins that aren't in compiler_rt HOT 9
- AEABI division function linking problems (again) HOT 2
- duplicated intrinsic implementations linked into libstd HOT 4
- libm directory is missing from 0.1.97 crates.io release HOT 2
- wrong define of 128-bit related functions like `__multi3` and `__floatuntidf` on `csky` HOT 4
- The `USE_NATIVE_FULL_ITERATIONS` codepath in `div64` is broken
- Several functions perform out-of-bounds memory accesses (which is UB) HOT 16
- undefined reference to `memcpy`, undefined reference to `memset` HOT 1
- `__extenddftf2` is found to be missing at runtime when using the WASI SDK to build Rust crates' C code HOT 1
- Getting C-defined intrinsics into a project that uses the stable compiler doesn't work because of all the `#![feature]` checks HOT 2
- Unable to find long double symbols on `aarch64-apple-darwin` HOT 4
- Adding feature to port `libm` for any target HOT 3
- Unable to use static macOS libraries in Unreal Engine projects HOT 2
- Regression: build failure on i686-pc-windows-gnu due to multiple definition of `_alloca` HOT 15
- Undefined reference to __chkstk, __alloca when building target i686-unknown-uefi
- aarch64 windows build failure HOT 1
- `aarch64-linux` `multf3` symbol has incorrect rounding HOT 1
- Unable to `-Zbuild-std` because std depends on `compiler-builtins` without the `no-f16-f128` features HOT 4
- Rounding error in `__mulsf3` HOT 6
- Inconsistent truncation of -0.0 HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from compiler-builtins.