arm64e: set ptrauth ABI subtype on lib.rmeta Mach-O objects

[cypherair]

Set CPU_SUBTYPE_PTRAUTH_ABI (as well as the existing CPU_SUBTYPE_ARM64E) on ARM64e object files that rustc creates, to match Clang/LLVM-generated ARM64e objects.

This corresponds to cpusubtype == 0x80000002. Before this change, rustc emitted the bare CPU_SUBTYPE_ARM64E subtype for the metadata wrapper objects / symbols.o file, producing 0x00000002, which can be reported by Apple's linker as arm64e.old.

Fixes rust-lang/rust#130085.
Fixes rust-lang/rust#143844.
Fixes rust-lang/rust#150046.
Fixes rust-lang/rust#139218.

[rustbot]

Some changes occurred in src/doc/unstable-book/src/compiler-flags/branch-protection.md

cc @rust-lang/project-exploit-mitigations, @rcvalle

These commits modify compiler targets.
(See the Target Tier Policy.)

[rustbot]

r? @adwinwhite

rustbot has assigned @adwinwhite.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 73 candidates
• Random selection from 19 candidates

[madsmtm]

r? me

[madsmtm]

My understanding of the ARM64e situation is that it cannot be solved in rustc, it needs LLVM work? Or rather, it needs Apple to upstream their LLVM changes?

[cypherair]

Thanks for pointing this out. I updated the title and description to make the scope clearer.

This PR doesn’t provide full Apple arm64e support. It covers the rustc-side ptrauth codegen pieces for Rust’s own codegen paths, and full arm64e support still needs LLVM work.

[cypherair]

I’m converting this PR back to draft while I re-check its scope and fix gaps in the current implementation.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[cypherair]

Thanks, I’ve removed the test. I really appreciate your time reviewing this and your guidance.

[madsmtm]

Thanks for fixing this! I've shortened the PR description a bit, and added issues that this fixes.

@bors r+ rollup

[rust-bors]

📌 Commit 8c029d5 has been approved by madsmtm

It is now in the queue for this repository.

[cypherair]

Thanks again for your review!

[oskarwirga]

My understanding of the ARM64e situation is that it cannot be solved in rustc, it needs LLVM work? Or rather, it needs Apple to upstream their LLVM changes?

Good news is we are not blocked on Apple upstreaming LLVM changes anymore. Currently, end-to-end arm64e support for Rust is chiefly blocked on backend Mach-O support which I put up for review here: llvm/llvm-project#188378

I've been able to successfully build and link arm64e Rust applications using that patch as well this commit where I add support for C/C++ interop w/ appropriate pointer signing schemas: oskarwirga@fbcad35

It should be noted however I am not an expert in rustc and that was put together through trial and error :P

[madsmtm]

Currently, end-to-end arm64e support for Rust is chiefly blocked on backend Mach-O support which I put up for review here

Ohh, nice work! I'll probably be looking into pointer authentication myself soon as part of reviewing #155722, then I'll probably be able to help with getting things landed in rustc. Feel free to r? madsmtm if you post it as a PR here at some point.