Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow atomic operations up to 32 bits #44978

Merged
merged 1 commit into from
Oct 8, 2017
Merged

Allow atomic operations up to 32 bits #44978

merged 1 commit into from
Oct 8, 2017

Conversation

jamesmunns
Copy link
Member

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:

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.

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.
@rust-highfive
Copy link
Collaborator

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.

@jamesmunns
Copy link
Member Author

Tagging @alexcrichton and @japaric as they provided advice for this PR at Rustfest's Impl Days.

Copy link
Member

@japaric japaric left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@arielb1
Copy link
Contributor

arielb1 commented Oct 2, 2017

r? @japaric

@rust-highfive rust-highfive assigned japaric and unassigned arielb1 Oct 2, 2017
@carols10cents carols10cents added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 2, 2017
@mattico
Copy link
Contributor

mattico commented Oct 2, 2017

Do we link to libgcc.a? If not does it make sense to say "this platform supports atomics" when a compiled rust program won't actually support atomics?

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 alexcrichton added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 4, 2017
@alexcrichton
Copy link
Member

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!

@Amanieu
Copy link
Member

Amanieu commented Oct 4, 2017

@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).

@alexcrichton
Copy link
Member

Ok sounds like there's not too many other thoughts from @rust-lang/libs, so let's merge!

@bors: r+

@bors
Copy link
Contributor

bors commented Oct 6, 2017

📌 Commit 1e26094 has been approved by alexcrichton

@bors
Copy link
Contributor

bors commented Oct 7, 2017

⌛ Testing commit 1e26094 with merge 799038c244df31cbda515cd70629889a4c255892...

@bors
Copy link
Contributor

bors commented Oct 7, 2017

💔 Test failed - status-travis

@alexcrichton
Copy link
Member

@bors: retry

  • filetime-0.1.13 broke this, I've yanked that and will fix.

@bors
Copy link
Contributor

bors commented Oct 8, 2017

⌛ Testing commit 1e26094 with merge f47f53c...

bors added a commit that referenced this pull request Oct 8, 2017
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].
@bors
Copy link
Contributor

bors commented Oct 8, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing f47f53c to master...

@bors bors merged commit 1e26094 into rust-lang:master Oct 8, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants