Allow atomic operations up to 32 bits #44978
Conversation
The ARMv5te platform does not have instruction-level support for atomics, however the kernel provides [user space helpers](https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt) which can be used to perform atomic operations. When linked with `libc`, the atomic symbols needed by Rust will be provided, rather than CPU level intrinsics. As this target is specifically `linux` and `gnueabi`, it is reasonable to assume the Linux Kernel and libc will be available for the target. There is a large performance penalty, as we are not using CPU level intrinsics, however this penalty is likely preferable to not having the target at all. I have used this change in a custom target (along with `xargo`) to build `std`, as well as a number of higher level crates.
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @arielb1 (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
Tagging @alexcrichton and @japaric as they provided advice for this PR at Rustfest's Impl Days. |
|
r? @japaric |
carols10cents
added
the
S-waiting-on-review
|
Do we link to Also, I'm not quite sure why rust-lang/compiler-builtins#115 has stalled, but that PR only adds support for ARMv6, not ARMv5. |
alexcrichton
added
T-libs-api
|
Looks great to me, thanks @jamesmunns! cc @rust-lang/libs This is different from what we've previously said as the architecture has no support for atomic operations. Notably, armv5 in this case I believe has no atomic instructions. That being said, however, the platform has support for atomic instructions which is what the compiler-builtins/libgcc intrinsics call into (described above). After talking with @jamesmunns in person I'm convinced this is the right way to go. These still aren't the most performance things in the world but I'm not sure if there's a whole lot of downsides to doing this. Figured I'd give others a chance to comment before merging though! |
|
@mattico Just a small correction, my PR adds support for atomics on ARMv5 (and potentially ARMv4 as well but that requires some changes to the inline asm). |
|
Ok sounds like there's not too many other thoughts from @rust-lang/libs, so let's merge! @bors: r+ |
|
📌 Commit 1e26094 has been approved by |
|
⌛ Testing commit 1e26094 with merge 799038c244df31cbda515cd70629889a4c255892... |
|
💔 Test failed - status-travis |
|
@bors: retry
|
Allow atomic operations up to 32 bits The ARMv5te platform does not have instruction-level support for atomics, however the kernel provides [user space helpers] which can be used to perform atomic operations. When linked with `libgcc`, the atomic symbols needed by Rust will be provided, rather than CPU level intrinsics. [user space helpers]: https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt 32-bit versions of these kernel level helpers were introduced in Linux Kernel 2.6.12, and 64-bit version of these kernel level helpers were introduced in Linux Kernel 3.1. I have selected 32 bit versions as std currently only requires Linux version 2.6.18 and above as far as I am aware. As this target is specifically linux and gnueabi, it is reasonable to assume the Linux Kernel and libc will be available for the target. There is a large performance penalty, as we are not using CPU level intrinsics, however this penalty is likely preferable to not having the target at all. I have used this change in a custom target (along with xargo) to build std, as well as a number of higher level crates. ## Additional information For reference, here is what a a code snippet decompiles to: ```rust use std::sync::atomic::{AtomicIsize, Ordering}; #[no_mangle] pub extern fn foo(a: &AtomicIsize) -> isize { a.fetch_add(1, Ordering::SeqCst) } ``` ``` Disassembly of section .text.foo: 00000000 <foo>: 0: e92d4800 push {fp, lr} 4: e3a01001 mov r1, #1 8: ebfffffe bl 0 <__sync_fetch_and_add_4> c: e8bd8800 pop {fp, pc} ``` Which in turn is provided by `libgcc.a`, which has code which looks like this: ``` Disassembly of section .text: 00000000 <__sync_fetch_and_add_4>: 0: e92d40f8 push {r3, r4, r5, r6, r7, lr} 4: e1a05000 mov r5, r0 8: e1a07001 mov r7, r1 c: e59f6028 ldr r6, [pc, #40] ; 3c <__sync_fetch_and_add_4+0x3c> 10: e5954000 ldr r4, [r5] 14: e1a02005 mov r2, r5 18: e1a00004 mov r0, r4 1c: e0841007 add r1, r4, r7 20: e1a0e00f mov lr, pc 24: e12fff16 bx r6 28: e3500000 cmp r0, #0 2c: 1afffff7 bne 10 <__sync_fetch_and_add_4+0x10> 30: e1a00004 mov r0, r4 34: e8bd40f8 pop {r3, r4, r5, r6, r7, lr} 38: e12fff1e bx lr 3c: ffff0fc0 .word 0xffff0fc0 ``` Where you can see the reference to `0xffff0fc0`, which is provided by the [user space helpers].
|
☀️ Test successful - status-appveyor, status-travis |
The ARMv5te platform does not have instruction-level support for atomics, however the kernel provides user space helpers which can be used to perform atomic operations. When linked with
libgcc, the atomic symbols needed by Rust will be provided, rather than CPU level intrinsics.32-bit versions of these kernel level helpers were introduced in Linux Kernel 2.6.12, and 64-bit version of these kernel level helpers were introduced in Linux Kernel 3.1. I have selected 32 bit versions as std currently only requires Linux version 2.6.18 and above as far as I am aware.
As this target is specifically linux and gnueabi, it is reasonable to assume the Linux Kernel and libc will be available for the target. There is a large performance penalty, as we are not using CPU level intrinsics, however this penalty is likely preferable to not having the target at all.
I have used this change in a custom target (along with xargo) to build std, as well as a number of higher level crates.
Additional information
For reference, here is what a a code snippet decompiles to:
Which in turn is provided by
libgcc.a, which has code which looks like this:Where you can see the reference to
0xffff0fc0, which is provided by the user space helpers.