-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for arm64e ABI (when possible) #4490
Comments
See also #4487 |
Yes, if you support emitting code for iOS (AOT, I guess, given iOS platform restrictions), you will need to support emitting code for pointer authentication. If you don't need to generate any indirect calls, that should be very easy — just a small amount of driver setup. Otherwise, it might be more complex. |
Adding @abadams @alexreinking -- we have a request internal to Google about supporting this (I'm rather surprised it hasn't come up before now, in hindsight). My guess is that if LLVM supports it directly (which I'd hope to be the case by now) then this should be fairly straightforward; if not.... well, not? |
I think it hasn't come up because Apple backed off on requiring it. I don't know how complex it would be to add. It might just work, but it's also possible there could be LLVM IR passes we have to do over the runtime modules, because target-agnostic bitcode isn't enough. |
The iOS JIT entitlement requires arm64e. Users could also potentially want to run your code in an arm64e process on macOS for security reasons. It's not urgent If you don't have users actually asking for these things, of course. |
As of July 2024, the support for arm64e in upstream LLVM doesn't appear to match that in recent XCode versions, so it's not really useful. This will likely need to wait for Apple to upstream their fixes from their private branch into the main branch. |
See http://lists.llvm.org/pipermail/llvm-dev/2019-October/136091.html
This will likely be necessary in order to work with versions of Xcode (etc) that enable the pointer-authentication features for newer (A12+) chips.
Note that ARMv8.3a support is somewhat orthogonal to this; arm64e presumes/requires ARM8.3a to be available, but the reverse it not necessarily the case, AFAIK.
The text was updated successfully, but these errors were encountered: