[libcxx-commits] [libcxx] [libcxxabi] [libc++][libc++abi] Minor follow-up changes after ptrauth upstreaming (PR #87481)

[Ahmed Bougacha via libcxx-commits]

================
@@ -275,13 +275,15 @@ struct __type_info_implementations {
           __impl;
 };
 
-#    if defined(__arm64__) && __has_cpp_attribute(clang::ptrauth_vtable_pointer)
-#      if __has_feature(ptrauth_type_info_discriminated_vtable_pointer)
+#    if __has_cpp_attribute(_Clang::__ptrauth_vtable_pointer__) && __has_feature(__ptrauth_calls__)
+#      if __has_feature(__ptrauth_vtable_address_discrimination__) ||                                                  \
+          __has_feature(__ptrauth_vtable_type_discrimination__)
----------------
ahmedbougacha wrote:

Yes, we shouldn't do this change here, it does the opposite of what we want:  the ptrauth (current arm64e, or elf pauthabi) ABI does sign vtable pointers with type/address discrimination.  But it specifically doesn't sign the type info vtable pointer, which is why we need this special annotation, to override the default vtable ptr discrimination (that's exposed with the `ptrauth_vtable_address_discrimination`/`ptrauth_vtable_type_discrimination` features) to match the type info vtable codegen.

Since then we have indeed added support for signing these, and that's indeed denoted by `ptrauth_type_info_discriminated_vtable_pointer`.  So I think the version that's in tree today is doing the right thing, and honoring clang's directive given its understanding of the ABI.  (I don't mind and I'm not worried about removing the arm64 check FWIW).

We'll open a clang PR to add `ptrauth_type_info_discriminated_vtable_pointer`.  But looking at it now I think we'll want to rename it first, so let's settle that this week before it's too late (cc @ojhunt)

@kovdan01 to answer your specific questions:  in general I do think these should check something else than ptrauth features, because the specific decisions are made by a specific platform ABI, and isn't set in stone for all ptrauth.  Concretely, for the soft ptrauth example, a real soft ptrauth implementation could very well force these to be always discriminated, and use a different key (soft ptrauth not being constrained by HW keys, it uses a different key for every single ABI usage;  it could use one for "type info vtable ptrs").
In practice there likely won't ever be a serious and meaningfully different ptrauth ABI, so this doesn't seem like a real problem either way.

https://github.com/llvm/llvm-project/pull/87481