Add atomic support for pre-ARMv6 on Linux #115
Conversation
|
Perhaps this could be behind an off-by-default feature? For inclusion into rustc at least we'll want to turn off these intrinsics for now. |
|
I don't see why these intrinsics should be hidden behind a feature. They are never called by rustc on any of the currently available ARM targets. |
|
The compiler likes to have very strict control over the symbols it exposes and provides, so if we don't need these symbols we wouldn't want them exported. Because they're not called is just motivation for not having them in the first place as part of the compiler build (e.g. an off-by-default feature) |
|
Actually |
Amanieu
force-pushed
the
linux-arm-atomic
branch
from
3e9f172 to
f2a8e96
Compare
|
I moved the code behind the |
|
Hi team! Are there any further steps left before landing this patch? |
|
This pull request was brought up here. The OP of this reddit had to revert to 1.13 to get things working on ARMv5TE since newer std requires atomic instructions or some similar service. Would this patch allow compiling for ARMv5TE with the current std? |
|
@nelsonjchen |
|
@mattico Actually, the compiler-rt implementations of these intrinsics in compiler-rt uses ARMv6 instructions and won't work on ARMv4/ARMv5. The libgcc version does support ARMv4/ARMv5 though. |
|
☔ The latest upstream changes (presumably #194) made this pull request unmergeable. Please resolve the merge conflicts. |
|
@Amanieu I think with discussion on rust-lang/rust#44978 as of recently we're leaning towards merging this now? Would you be willing to rebase this on master? |
Amanieu
force-pushed
the
linux-arm-atomic
branch
from
f2a8e96 to
57a14df
Compare
|
Rebased. Do we still want this behind the "arm_linux_atomic" feature? I think these should always be available (the symbols are already exported by libgcc/libcompiler-rt, so we aren't adding any new symbols). |
|
Thanks! With the discussion on the linked PR I think we'd unconditionally provide these symbols on armv5 Linux, but nowhere else. |
|
Do I need to do anything in the PR or can I just leave it as a feature? |
|
Yes let's have compilation or not be automatic, detected based on the target (no features required) |
|
Do we have any way to differentiate the different ARM targets? AFAIK they all return the same thing for |
|
We've got a build script! |
Amanieu
force-pushed
the
linux-arm-atomic
branch
from
57a14df to
73e38dc
Compare
|
Done. |
|
Looks great! I'll hold off on merging until rust-lang/rust#44978 is decided on, but I think we're very likely to merging that. Thanks for the updates here! |
|
@bors: r+ |
|
📌 Commit 73e38dc has been approved by |
Add atomic support for pre-ARMv6 on Linux This uses the [kernel user helpers](https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt) which are available starting from kernel 2.6.15. Since Rust currently requires 2.6.18 at a minimum, this should be fine in practice. I did not include support for 64-bit atomics since that functionality is only available in kernel 3.1. This PR allows Rust to work on older ARM versions such as ARMv4 and ARMv5 with the full libstd.
|
☀️ Test successful - status-appveyor, status-travis |
| unsafe fn __kuser_cmpxchg(oldval: u32, newval: u32, ptr: *mut u32) -> bool { | ||
| let out: u32; | ||
| // FIXME: we can't use BLX on ARMv4 | ||
| asm!("blx ${0}" |
There was a problem hiding this comment.
Just wondering, couldn't 0xffff0fc0u32 just be transmuted to a function pointer and then called instead of using inline assembly, then the compiler will take care of what branch instruction is used?
There was a problem hiding this comment.
Using inline asm is actually more efficient in this case since we can precisely specify which registers are clobbered by the call. This allows the compiler to avoid unnecessary spills. The set of clobbered registers is guaranteed by the kernel ABI.
Now that you mention it though, for __kuser_cmpxchg the clobber list is pretty much identical to that of a normal function, so there probably isn't much benefit there...
|
Just as a heads-up: The kernel helpers for older ARM targets conflict with the helpers provided by newer gcc versions, see: rust-lang/rust#48625 So we need to make the use of the helpers more fine-grained. |
This uses the kernel user helpers which are available starting from kernel 2.6.15. Since Rust currently requires 2.6.18 at a minimum, this should be fine in practice. I did not include support for 64-bit atomics since that functionality is only available in kernel 3.1.
This PR allows Rust to work on older ARM versions such as ARMv4 and ARMv5 with the full libstd.