Tracking issue for supporting macOS on Apple Silicon (a.k.a arm64, M1, M2, aarch64)

[shepmaster]

On 2020-06-22, Apple announced that future computers will utilize Arm processors instead of x86_64 processors. This is the tracking issue for supporting that platform, commonly referred to as Apple Silicon.

⚠️ Don't rely on this thread to decide whether to purchase Apple Silicon hardware. ⚠️
The Rust project does not make any guarantee on the level of support the compiler has.

Current status summary (2022-07-05)

• There is no timeline for any level of support.

• 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. This is a blocker for Tier 1 support.

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

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. There are no members of the compiler team actively working on this
• 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.
• Achieve Tier 3 support:
  • Wait for proper support to be upstreamed into LLVM, and update the Rust compiler to pull the latest version of LLVM.
    • Our current LLVM supports targeting the appropriate hardware well enough.
  • Update the libc crate's conditional compilation to account for the new target.
    • Limit macOS $INODE64 symbol names to x86 and x86_64 libc#1817 (in libc 0.2.73)
  • Update the cc crate to account for the new target.
    • https://github.com/alexcrichton/cc-rs/pull/527 (in cc 1.0.58)
  • Submit an initial target specification for aarch64-apple-darwin.
    • Add the aarch64-apple-darwin target  #74541
  • Get the target specification into the bootstrap compiler.
    • Add the aarch64-apple-darwin target  #74541
    • [beta] backports #75261
• Achieve Tier 2 support:
  • Get Xcode 12 on our CI
  • Update the openssl-src crate to account for the new target.
    • Add upstream patch to allow building on aarch64-apple-darwin alexcrichton/openssl-src-rs#74
  • Setup a cross-compiling builder to reach Tier 2
    • Add to CI (Set up CI for aarch64-apple-darwin #75991)
    • Build Cargo (Enable building Cargo for aarch64-apple-darwin #77239)
    • Distribute binaries (Include aarch64-apple-darwin in the dist manifests #77895)
• Achieve Tier 1 support:
  • Entire test suite passes
    • Variadic FFI test fails on aarch64-apple-darwin #78092
    • LLVM assertion failure after activating LTO on aarch64-apple-darwin #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
  • Rustup
    • Add support to rustup (Build for aarch64-apple-darwin rustup#2521)
    • Release it (Provide full Apple Silicon (arm64/AArch64-Apple-Darwin) support in rustup rustup#2413)

Resolved Questions

• The infra team does not want to maintain our own hardware / VMs. This means solutions like MacStadium, AWS, or "putting our own hardware under someone's desk" are non-starters.

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?
  • Support for VMs on Apple M1 actions/runner-images#2187
  • GitHub Actions: Apple Silicon (M1) powered macOS runners (Public Beta) github/roadmap#528
• Should we use an alternative / additional CI provider to GitHub?
  • Cirrus CI
• 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

[hasanihunter]

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

[shepmaster]

is there any way they can help

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

[rudyrichter]

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

[shepmaster]

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

[shepmaster]

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.

[Absolucy]

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.

[glandium]

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)