Rust: Tracking issue for supporting macOS on Apple Silicon (ARM)

Created on 1 Jul 2020  Â·  19Comments  Â·  Source: rust-lang/rust

Apple has announced that future computers will utilize ARM processors instead of x86_64 processors. This is a tracking issue for supporting that platform.

:warning: Don't rely on this thread to decide whether to purchase Apple hardware with ARM. :warning:
The Rust project can't make any guarantee on the level of support the compiler will have when the hardware ships.

Current status summary (2020-09-18)

  • There is no timeline for any level of support.

  • The x86_64 version of rustc works under Rosetta, producing x86_64 binaries that themselves run under Rosetta.

  • aarch64-apple-darwin is a tier 2 target and is available for download via rustup. This compiler can be used to cross-compile from x86_64-apple-darwin as well as running natively on ARM.

  • Compiler tests are not being run at this point, as CI has no way of executing them.

About tracking issues

Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.

A tracking issue is not meant for large scale discussion, questions, or bug reports about a feature. Instead, join the discussion and/or contribute in the #t-compiler/arm Zulip stream or open a new issue for bug reports. You are encouraged to comment here to link to related issues.

This tracking issue will be closely moderated in an attempt to maintain a high signal-to-noise ratio.

Steps

This is not yet intended to be an exhaustive or even accurate list of steps.

  • [ ] Find out if there is anyone inside the compiler team with the time to drive the effort forward. This will allow us to efficiently allocate the Developer Transition Kits (DTK), if we end up receiving any.
  • [x] Reach out to our contacts at Apple to see if DTKs are available, and to establish a line of communication if there are problems down the line. Please coordinate with the leads of the compiler and infra teams on Zulip on this.
  • [x] Achieve Tier 3 support:
  • [x] Achieve Tier 2 support:

    • [x] Get Xcode 12 on our CI

    • Update the openssl-src crate to account for the new target.

    • [x] https://github.com/alexcrichton/openssl-src-rs/pull/74

    • Setup a cross-compiling builder to reach Tier 2

    • [x] Add to CI (https://github.com/rust-lang/rust/pull/75991)

    • [x] Build Cargo (https://github.com/rust-lang/rust/pull/77239)

    • [x] Distribute binaries (https://github.com/rust-lang/rust/pull/77895)

  • [ ] Achieve Tier 1 support:

    • [ ] Entire test suite passes

    • [x] #78092

    • [ ] #78881

    • [ ] Increase the quality and reliability of the target

    • [ ] Hook up target hardware to our CI, and start running the test suite as part of our standard QA process.

    • [ ] Propose the promotion to Tier 1.

  • Miscellaneous

    • [ ] Add support to rustup (https://github.com/rust-lang/rustup/pull/2521)

Unresolved Questions

This is not yet intended to be an exhaustive or even accurate list of questions.

  • [ ] When will our CI providers have access to native hardware?
  • [ ] What is an accurate target name for the new platform?

    • [ ] What is the accurate name of the chip ("silicon", "aarch64", "arm64", etc.)?

  • [ ] How can we leave room to support Apple's arm64e?

Implementation history

C-tracking-issue O-ARM O-macos T-compiler T-infra

Most helpful comment

Status update

Progress has continued at a measured pace. You can see a summary of the work to date in the "Current status summary" section in the top post. The most recent update is that aarch64-apple-darwin is now a Tier 2 platform. It is important to note that the compiler tests are not being run at this point, as CI has no way of executing them.

If you'd like to try using the new compiler, I've created some basic instructions on how to configure your project to cross-compile to aarch64-apple-darwin. If you have access to an Apple DTK, there are also instructions on how to download and install the native toolchain.


As a reminder:

A tracking issue is not meant for large scale discussion, questions, or bug reports about a feature. Instead, join the discussion and/or contribute in the #t-compiler/arm Zulip stream or open a new issue for bug reports. You are encouraged to comment here to link to related issues.

All 19 comments

For those devs that have a DTK in their possession, is there any way they can help?

is there any way they can help

join the discussion in the #t-compiler/arm Zulip stream

@shepmaster is there any help needed getting to the point where one can cross-compile targeting the new architecture from an existing one (macOS x86_64 cross compiling for macOS arm64) ?

@rudyrichter no, we have that capability already — see the "Current status summary" section in the top post. Please feel free to join Zulip if you have more questions.

Status update

Thanks for your patience! Progress has continued at a suitable pace. If you haven't been refreshing the page manually every few hours, you can see a summary of the work to date in the "Current status summary" section in the top post. The most recent update is that we have opened a pull request to add an appropriate target to the compiler codebase. Next steps include getting that merged into nightly and then present in the bootstrapping compiler. Once that's available, we will be able to look into getting builds as part of CI.


As a reminder:

A tracking issue is not meant for large scale discussion, questions, or bug reports about a feature. Instead, join the discussion and/or contribute in the #t-compiler/arm Zulip stream or open a new issue for bug reports. You are encouraged to comment here to link to related issues.

How can we leave room to support Apple's arm64e?

I am currently adding PAC/arm64e to a fork using Apple's LLVM. Hopefully some of my work can be reused whenever PAC/arm64e support is upstreamed into LLVM.

Not sure if I should open a separate issue, but running the x86-64 rustc on a DTK (via Rosetta 2) yields <jemalloc>: Unsupported system page size messages (but things still work), so it's likely that the arm64 port would need some adjustment in that area. (Not sure if the x86-64 rustc should be adjusted to to work without those messages under Rosetta 2)

(The issue being that the page size is 16KB instead of 4KB)

For the record, I've built the rust compiler on the DTK with https://github.com/rust-lang/rust/pull/75500, a tweak to stage0.txt to pick a recent nightly, and a config.toml that sets the following:

build = "x86_64-apple-darwin"
host = ["aarch64-apple-darwin"]
target = ["aarch64-apple-darwin"]

and was subsequently able to build all the rust code in Firefox but I had to make changes to three crates that were passing the wrong --target to clang because the rust target differs from the clang target (rust uses aarch64-apple-darwin, clang uses arm64-apple-darwin). This is very unfortunate, and it's probably going to cause problems in other crates.

I'm throwing a link to https://github.com/rust-lang/rust/issues/74820 on here because I suspect we'll want to better understand that bug before we can stabilize a Tier 1 ARM target.

I'm throwing a link to #74820 on here because I suspect we'll want to better understand _that_ bug before we can stabilize a Tier 1 ARM target.

Does _that_ bug affect any 64-bit ARM targets? Or just ARMv7?

Note from issue janitor @shepmaster: A tracking issue is not meant for large scale discussion, questions, or bug reports about a feature. Instead, please take any questions about #74820 to #74820.

Get Xcode 12 on our CI, and setup a cross-compiling builder to reach Tier 2.

It's already there, both on github actions and azure pipelines, per https://github.com/actions/virtual-environments/blob/main/images/macos/macos-10.15-Readme.md and https://github.com/microsoft/azure-pipelines-image-generation/blob/master/images/macos/macos-10.15-Readme.md (which look like to be the same document, btw)

Status update

Thanks for your patience! Progress has continued at a slow pace. You can see a summary of the work to date in the "Current status summary" section in the top post. The most recent update is that we have opened a draft pull request to add a cross-compiler builder as part of CI. Once that is reviewed and hopefully merged, then artifacts should be available to download. It is important to note that the compiler tests are not being run at this point, as CI has no way of executing them.


As a reminder:

A tracking issue is not meant for large scale discussion, questions, or bug reports about a feature. Instead, join the discussion and/or contribute in the #t-compiler/arm Zulip stream or open a new issue for bug reports. You are encouraged to comment here to link to related issues.

Status update

Progress has continued at a measured pace. You can see a summary of the work to date in the "Current status summary" section in the top post. The most recent update is that aarch64-apple-darwin is now a Tier 2 platform. It is important to note that the compiler tests are not being run at this point, as CI has no way of executing them.

If you'd like to try using the new compiler, I've created some basic instructions on how to configure your project to cross-compile to aarch64-apple-darwin. If you have access to an Apple DTK, there are also instructions on how to download and install the native toolchain.


As a reminder:

A tracking issue is not meant for large scale discussion, questions, or bug reports about a feature. Instead, join the discussion and/or contribute in the #t-compiler/arm Zulip stream or open a new issue for bug reports. You are encouraged to comment here to link to related issues.

The instructions to install rustup under the section "Compiling on native aarch64 hardware" no longer seem to work. Is there an updated command?

The instructions to install rustup under the section "Compiling on native aarch64 hardware" no longer seem to work.

What kind of error are you getting?

I'm seeing this:

me@my-Mac ~ % arch --x86_64 \
sh <(curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs) \
--default-host aarch64-apple-darwin \
--default-toolchain nightly
arch: posix_spawnp: sh: Bad CPU type in executable
me@my-Mac ~ % curl: (23) Failed writing body (0 != 710)

I just noticed an update to BigSur 11.0.1, I'll try updating. But these instructions seem to predate that release.

That command still works for me on beta 10.

It seems your sh is not a fat binary with x86_64. Did you build one yourself and put it first in your PATH ? Maybe write the full path to Apple's /bin/sh in the command line ?

Looks like this is a problem with my DTK:

me@my-Mac ~ % lipo -info /bin/sh
Architectures in the fat file: /bin/sh are: x86_64 arm64e 
me@my-Mac ~ % arch -arch x86_64 /bin/sh
arch: posix_spawnp: /bin/sh: Bad CPU type in executable
Was this page helpful?
0 / 5 - 0 ratings