Add support for visionOS targets

[conradev]

Proposal

Apple recently released the first version of the visionOS SDK for their Apple Vision Pro device. The device has standalone operating system and corresponding SDK called xrOS, much like the Apple Watch has watchOS or the Apple TV has tvOS.

Apple is using the platform names xros and xrsimulator for the Vision devices and Vision simulator, respectively. In this proposal, I want to add these new targets to Rust:

• aarch64-apple-xros
• aarch64-apple-xros-sim
• x86_64-apple-xros-sim

The corresponding LLVM targets are:

• arm64-apple-xros
• arm64-apple-xros-simulator
• x86_64-apple-xros-simulator

There is also arm64e-apple-xros, but afaik Rust doesn't support PAC yet on Apple OSes

Mentors or Reviewers

• conradev

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

cc @rust-lang/compiler @rust-lang/compiler-contributors

[Nilstrieb]

you need to fill out all the questions for new targets

[thomcc]

Isn't that just needed for the impl PR?

[thomcc]

I can volunteer for the implementation or the review. I was planning on doing the implementation for these anyway, as just did tvOS, but don't mind if someone else does this.

However, as discussed in Zulip there are some issues that prevent working on this in the near term:

• We're blocked by Apple upstreaming LLVM support for these -- doing it based on the LLVM from the preview SDK (similar to how we used to need to use the LLVM from the watchOS SDKs for those targets) is very painful.
• It is likely that these will not be the final target names.

[workingjubilee]

Isn't that just needed for the impl PR?

An MCP is technically not required at all. Rather, what is actually important is the requirements of the target tier policy are addressed by the author and the compiler team reviews it. An MCP is simply a vessel for that review.

[coolbluewater]

Hi folks, what is the status of this?

@thomcc

It is likely that these will not be the final target names.

I'm sure many developers, including myself, are eagerly awaiting this support.
To unblock here are a couple of choices:

1. Adopt the proposed target names based on 'xros' in nightly and change them down the road if Apple changes them, or
2. Adopt the seemingly committed brand name of 'visionOS' (which is what appears in user-facing text e.g. in Xcode).

I for one prefer the second option - it makes sense even if Apple continues to use the 'xros` name internally. We already have the precedent of a divergent naming convention in Rust for macOS ('darwin'), where both macOS and darwin seem reasonable choices.

Either way, hope that this issue progresses quick. It's problematic for a major OS to be impeded in this way, especially for simple Tier 3 support.

Thanks a lot folks!

[thomcc]

The status is that as far as I can tell, these are not in upstream LLVM (rg -e '(xros|visionos)' has no hits in LLVM main) so we still are blocked on that. We can't land support for them based on just the compilers in SDKs (or even based on Apple's LLVM fork). Note that even if this happens, we probably need to wait for them to be present in a released version of LLVM, so optimistically it could be LLVM 18, but maybe 19 (and that's assuming apple upstreams this to LLVM -- if they don't do that, then the path to support is more difficult).

The names are not a blocker.

[coolbluewater]

Understood. You mentioned that the tvOS scenario parallels this one. What were the issues/PRs that caused the needed changes to land upstream for tvOS? Who initiated those?

Also, what would it take to get a private build of Rust working against visionOS? Two or three versions of LLVM is a long time! :)

Thanks!

[workingjubilee]

Also, what would it take to get a private build of Rust working against visionOS? Two or three versions of LLVM is a long time! :)

There is a dev guide chapter on how to build the compiler. The Rust build system's config.toml has keys for specifying what LLVM you are building against and how you want to link (llvm-config and link-shared, amongst others). I recommend asking on Zulip if you need additional help building the compiler.

Also you will need to explain to rustc what the new targets are in rustc_target and thread the support for the new OS through std. Hopefully it doesn't do anything interesting and you can just pretend it's like iOS, or hopefully they document the relevant differences (in full and complete detail). Neither are necessarily the case which is kind of why we're waiting for the code to hit the open source LLVM.

[thomcc]

It's unclear how viable this is in practice since llvm-config isn't actually shipped with the XCode SDK, and it's not clear that everything else we need is shipped with it either.

My initial suspicion that we could use Apple's fork of LLVM (like we used to need to do for watchOS) might be wrong, since it doesn't seem to include xros or visionos, although I haven't looked carefully, perhaps it's in some branch.

If you get rustc to build against an LLVM that knows about visionos (or have questions), feel free to ping me and I can give some advice. Note that you'll be likely have to maintain a fork of rustc for a while to do this even if you get all that working, although perhaps we could merge some of the changes with the caveat that "for now you also need to build rustc against system LLVM").

It's also possible you could target the, err, target without direct LLVM support by building against a generic mach-o target and using various system tools to fix up the compilation artifacts, but it would likely be... quite painful.

[apiraino]

Closing this MCP on the concern that there is no LLVM support yet.

[lcapkovic]

Is this PR all that's needed to unblock this? Looks like Apple is upstreaming visionOS.
llvm/llvm-project#77707

[agg23]

I spent a decent amount of time trying to get vrOS working in the interim. I'm currently blocked on trying to build core which is failing with SIGTRAP, which I can only imagine is somehow LLVM is broken from the very minor changes adding xrOS.

My Zulip conversation asking about this build issue:
https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Adding.20new.2C.20near.20duplicate.20target.2E.20Failing.20building.20.60libc.60

LLVM changes (for some reason Apple's changes appear to not be complete):
rust-lang/llvm-project@rustc/17.0-2023-12-14...agg23:llvm-project:xrOS-target

rust:
rust-lang/rust@master...agg23:rust:xrOS-target

libc:
rust-lang/libc@main...agg23:libc:main

If anyone has any feedback, I'd love to hear it. I really want to get this working, and will help with getting this merged eventually (if that's desired), but for now I just want us to be able to target visionOS at launch.

[agg23]

To update: Apple's LLVM change is actually far from complete, and some core pieces of information are missing (such as IDs for new load commands in MachO). My build issues were solely due to LLVM being unable to actually build for the target due to these issues. I don't think that any meaningful progress will be made here until Apple graces us with more information.

[phatblat]

@agg23 It looks like some MachO stuff was added in llvm/llvm-project#78373. Does this include the load commands you were referring to?

[phatblat]

FYI, I don't think the x86_64-apple-xros-simulator target will be valid because it's called out very clearly in the Xcode 15.2 release notes:

Developing for visionOS requires a Mac with Apple silicon. (114799042)

[agg23]

No, I'm monitoring the llvm-project repo for any PRs submitted by Apple, and have been incrementally testing builds to see if that has the missing piece. What I am expecting is a LC_VERSION_MIN_XROS load command key (https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/BinaryFormat/MachO.def#L74) though I'm not sure that it's actually required (I don't really know what I'm doing here).

Apple appears to be making targeted changes that don't add xrOS all throughout LLVM, but just to very particular parts, and they're PRing incomplete segments of code (which I personally rather dislike), so it's hard to tell when it is usable.

---

I may have a working version of LLVM, but I don't know how to test outside of rustc. When attempting to build the stage 2 compiler libraries, which is the first time the compiler is used to produce native binaries (so aarch64-apple-macos building aarch64-apple-xros), ld notices something is wrong and fails with:

ld: building for 'visionOS', but linking in object file ... built for 'macOS'

I almost think this is a mistake I've made in the Rust side of things, but I don't know what it is. I started to log (inside of LLVM) the determined target OS, and at the point it switches to aarch64-apple-macos building aarch64-apple-xros, it starts reporting xrOS as the correct OS. Examining the binaries shows the MachO build command LC_BUILD_VERSION with the macOS id. So LLVM seems to know what we're talking about, and either is just not emitting the correct target OS (and potentially also the right code), or rustc is somehow instructing LLVM incorrectly.

I'm not really sure how to test LLVM in isolation to see if I can produce a suitable working binary. Going through clang would be too much of a pain, I think.

[agg23]

FYI, I don't think the x86_64-apple-xros-simulator target will be valid

Yes, I was silently ignoring this, but I don't believe you can run the simulator on anything besides Apple Silicon.

[agg23]

Apple has closed the issue, claiming that the LLVM support is complete (it's definitely not complete, but it may be functional). This suggests that I'm doing something wrong to prevent rustc from properly building the binaries.

[Nilstrieb]

(btw, I recommend opening a new zulip stream and posting updates their instead of here, which sends out GitHub notifications to many people)

[agg23]

I got things working, though it's a complicated setup. Hopefully there's not a problem with me posting it here as a discoverable way for people to find it.

My forks are:
https://github.com/agg23/rust/tree/xrOS-Target2
https://github.com/agg23/libc
https://github.com/agg23/llvm-project/tree/xrOS-Apple

Simulator Instructions

These should work for the actual target as well; just replace the -sim values.

1. Install xargo
2. Clone https://github.com/agg23/rust.git, checkout branch xrOS-Target2. Also checkout https://github.com/agg23/libc.git and https://github.com/agg23/object.git to the same root directory
3. Enter the rust directory. Cargo.toml already contains a libc and object patch to reference our cloned repo. Add this config.toml:

change-id = 102579
# These defaults are meant for users and distro maintainers building from source, without intending to make multiple changes.
[build]
# When compiling from source, you almost always want a full stage 2 build,
# which has all the latest optimizations from nightly.
build-stage = 2
test-stage = 2
doc-stage = 2
# When compiling from source, you usually want all tools.
extended = true

target = ["aarch64-apple-darwin"]

# Most users installing from source want to build all parts of the project from source.
[llvm]
download-ci-llvm = false
assertions = true
release-debuginfo = true
[rust]
# We have several defaults in bootstrap that depend on whether the channel is `dev` (e.g. `omit-git-hash` and `download-ci-llvm`).
# Make sure they don't get set when installing from source.
channel = "nightly"
download-rustc = false
deny-warnings = false

[dist]
# Use better compression when preparing tarballs.
compression-profile = "balanced"

4. Run ./x.py clean. This will build the Rust bootstrap and clone some core repos. You cannot run the subsequent commands without this.
5. Run cargo update -p libc and cargo update -p object to add the libc and object patch to Cargo.lock and ensure it's picked up
6. Run ./x.py build --stage 2 to build the compiler. We need to build the library at stage 2 for the host, not the target
7. Link toolchain via rustup toolchain link xrOS-toolchain build/host/stage2. xrOS-toolchain can be named whatever you want
8. Add rust-toolchain.toml and Xargo.toml files to your project

rust-toolchain.toml:

[toolchain]
channel = "xrOS-toolchain"

Xargo.toml:

[patch.crates-io]
libc = { git = "https://github.com/agg23/libc.git", rev = "db0fbbf6b554915eaffd42fb8703ab0b11625573" }

[target.aarch64-apple-xros-sim.dependencies.std]
features = ["panic-unwind"]

9. Force using the custom libc with: xargo update -p libc --precise 0.2.151 (updates Cargo.lock)
10. Build the project with xargo build --target aarch64-apple-xros-sim

Questions

If you have any questions or suggestions that are outside of the work required to integrate this target into Rust, please post on the Zulip chat.

[coolbluewater]

@agg23, thanks!
UPDATE 9:

@coolbluewater can we continue this discussion on Zulip? I would like to know what's going wrong with your build. I think you don't need -Zbuild-std, as that's what the hardcoded dependency in Xargo.toml is doing.

I get exactly the same errors with our without the -Zbuild-std so that's not an issue. It's really not worth diagnosing a corrupt compiler build; time better spent fixing the build first, agree? If you are able to test a fresh clone of your build instructions, that may save many hours of this back and forth.

UPDATE 8: While using the compiled toolchain on my project I run into many compiler issues. My expectation was that I can take a library that compiles using

xargo build --target aarch64-apple-ios-sim  -Zbuild-std=std

have it compile using

xargo build --target aarch64-apple-xros-sim -Zbuild-std=std

However, this isn't working so far, probably due to the manual patches which likely did not produce a kosher build. So need to build the toolchain without these hacks.

---

UPDATE 7: The build completed successfully with these fixes!

UPDATE 6: Looks like the error was a missing setter method in your version of 'object', so hand patched object/src/read/mod/rs and added the following at line 708:

    /// Set the addend to use in the relocation calculation.
    #[inline]
    pub fn set_addend(&mut self, addend: i64) {
        self.addend = addend
    }

Now rebuilding, fingers crossed...

UPDATE 5: I hand-patched the actual constants into compiler/rustc_target/src/spec/base/apple/mod.rs to make progress. Now I get this error:

error[E0599]: no method named `set_addend` found for struct `object::Relocation` in the current scope
   --> ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/thorin-dwp-0.7.0/src/relocate.rs:160:36
    |
160 |                         relocation.set_addend(addend as i64);
    |                                    ^^^^^^^^^^ help: there is a method with a similar name: `addend`

UPDATE 4: I thought it got further, but nope, still the same error. Also this:

warning: unexpected `cfg` condition value: `xros`
   --> <snip>/libc/src/unix/mod.rs:372:25
    |
372 |                         target_os = "xros",
    |                         ^^^^^^^^^^^^^^^^^^
    |

Are you able to test a second checkout, these issues ought to repro there.
Alternatively I'd also be happy to download a 1GB toolchain!

UPDATE 3: Needed cargo update -p object before running clean and build. Also deleted the 'build' folder, and now rebuilding.

UPDATE 2: Pulled from the rust repo, and cloned https://github.com/agg23/object.git alongside the rust repo.
Then ran ./x.py clean followed by ./x.py build --stage 2

However, get the same error during build. Interestingly the error comes from the same location, i.e. ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/object-0.32.1. So it's somehow not picking up the cloned object repo, even though it did complain when I tried building without cloning that repo.

[agg23]

Thank you. Fixed and instructions updated.

I would provide toolchain binaries so people can avoid compiling Rust, but it turns out the built toolchain is over 1GB, so I don't think it's worth the effort.

EDIT:

That is odd. I updated object, but I didn't think it fixed anything, but somehow my cargo registry has my modified code... I added a patch for it in the rust root Cargo.toml; pull https://github.com/agg23/object.git and see if that works. If so, I'll update my comment above.

EDIT 5-6:

That's very interesting. I don't believe I ever saw this error. Looks like the method was removed in gimli-rs/object@eb58357 which is unreleased on master. I must have edited the source in my cargo index for some bizarre reason, which is why I didn't encounter this. I will update object with the correct version later today.

EDIT 8:

@coolbluewater can we continue this discussion on Zulip? I would like to know what's going wrong with your build. I think you don't need -Zbuild-std, as that's what the hardcoded dependency in Xargo.toml is doing.

[agg23]

Currently waiting for rust-lang/rust#120055 to merge. PRs have been submitted to object and libc in preparation for the target.

[eugenehp]

@agg23 looks like rust-lang/rust#120055 is already merged.

[agg23]

The tier 3 target is now merged into the Rust compiler.

[eugenehp]

Amazing, thanks for pushing this! @agg23