ld64.lld doesn't seem to support arm64e

[glandium]

$ echo "int main() { return 0; }" > foo.c
$ clang --target=arm64e-apple-darwin -o foo foo.c -isysroot /path/to/MacOSX14.2.sdk -fuse-ld=lld
$ file foo
foo: Mach-O 64-bit arm64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>

When using plain ld64:

$ clang --target=arm64e-apple-darwin -o foo foo.c -isysroot /path/to/MacOSX14.2.sdk
$ file foo
foo: Mach-O 64-bit arm64e 00) executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>

[llvmbot]

@llvm/issue-subscribers-lld-macho

Author: Mike Hommey (glandium)

``` $ echo "int main() { return 0; }" > foo.c $ clang --target=arm64e-apple-darwin -o foo foo.c -isysroot /path/to/MacOSX14.2.sdk -fuse-ld=lld $ file foo foo: Mach-O 64-bit arm64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE> ``` When using plain ld64: ``` $ clang --target=arm64e-apple-darwin -o foo foo.c -isysroot /path/to/MacOSX14.2.sdk $ file foo foo: Mach-O 64-bit arm64e 00) executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE> ```

[glandium]

For the record, isArchABICompatible, compatWithTargetArch and createTargetInfo all ignore the cpuSubtype from the target.

[BertalanD]

I'd love to start working on this. Are there any objections or other folks already working on it?

cc. @rmaz @ellishg @alx32

[drodriguez]

@BertalanD feel free to work on this. We needed to clarify a couple more things and have not started to work on this or have time allocated to start. Could you mention us in future changes you make around arm64e support to keep track of it? Thanks.

[BertalanD]

I put up my WIP branch. This won't ever become a PR, I'm just trying to make things work with the least amount of refactoring/easiest hacks, and once I know the full scope of the required changes, we can think about refactoring code and doing it the proper way.

We'll need these changes:

• Reloc needs to store either a 64-bit addend (other architectures) or a 32-bit addend + authentication data (arm64e). Will need to use a union if we wish to keep Reloc's size down.
• Support for new pointer formats (ld64's source says these are used for macOS 12+; Chrome doesn't target older versions, so I'd say forget about the legacy format for now):
  dyld_chained_ptr_arm64e_rebase, dyld_chained_ptr_arm64e_auth_rebase, dyld_chained_ptr_arm64e_bind24, dyld_chained_ptr_arm64e_auth_bind24
• ChainedFixupsSection::addBinding needs to know whether it's an authenticated fixup, as only non-authenticated binds can store an addend in-line (low prio, just an optimization)
• We can't call writeChainedRebase directly from ConcatInputSection::writeTo, as that would drop auth data.
• split the GOT: __stubs loads pointers from __auth_got (signed with div=0x0000 ad=0 key=IA), address-taken globals/GOT relocations reference unsigned data in __got.
• Personality functions need to be signed according to ld64 (?)
• __thread_vars should sign __tlv_bootstrap pointers with div=0x0000 ad=0 key=IA even though they're emitted as non-signed by the assembler.
• Logic to set CPU_SUBTYPE_ARM64E_PTRAUTH_VERSION. macOS 15 and 26 beta refuse to load the binary if the ABI version is not 1.
• Range extension thunks, objc_msgSend stubs etc. should use signed pointers.
• Update ICF to handle ARM64_RELOC_AUTHENTICATED_POINTER (even __cfstring contains authenticated pointers)

Stay tuned for an in-depth gist with my findings about arm64e.

[oskarwirga]

@BertalanD Thanks so much for looking into this! I did some investigation into adding arm64e support as well and I've overlapped in a lot of areas you've talked about. I will upload my changes into a branch and provide the link shortly.

I've additionally been working off of swiftlang#8946 which is a bit dated but includes the same compiler flags that Xcode's Clang has, namely -fptrauth-objc-isa-mode=sign-and-strip & -fptrauth-abi-version=0 .

I am new to LLD so full-disclosure my patch is pretty vibe-coded, but I was able to get pretty good parity with Xcode strictly through my test cases. I also have been trying to use a small test iOS app to get parity but the fixups are still quite different (possibly due to missing swiftlang#8946)