Open steven-johnson opened 4 years ago
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.