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

[Daniil Kovalev 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__)
----------------
kovdan01 wrote:

A different signing schema is used for type info vtable pointers compared to other vtable pointers: see https://github.com/ahmedbougacha/llvm-project/blob/eng/arm64e-upstream-llvmorg/clang/include/clang/Basic/PointerAuthOptions.h#L246 (also see a comment in code for context). The reason is that in `ItaniumRTTIBuilder::BuildVTablePointer`, we only have mangled names of classes derived from `std::type_info`, and do not have full definitions with info about base class. So, we can't use type-dependent extra discrimination, since for vtable pointers, it relies on ability to look up base class definition. As for address discrimination for `type_info`-related vtable pointers, it could probably be supported on clang side, but it currently isn't.

Given that, in libcxx, previously, we unconditionally disabled type-based and address discrimination for type info vtable pointers. Here is the condition we used in downstream:

```
#if (defined(__arm64__) || defined(__aarch64__)) && \
    __has_feature(ptrauth_calls) && \
    __has_cpp_attribute(clang::ptrauth_vtable_pointer)
#define _LIBCPP_TYPE_INFO_VTABLE_POINTER_AUTH \
   [[clang::ptrauth_vtable_pointer(process_independent, no_address_discrimination, no_extra_discrimination)]]
#else
#define _LIBCPP_TYPE_INFO_VTABLE_POINTER_AUTH
#endif
```

I see that now type-based and address discrimination are enabled in libcxx under certain conditions: see https://github.com/ahmedbougacha/llvm-project/blob/eng/arm64e-upstream-llvmorg/libcxx/include/typeinfo#L278

```
#    if defined(__arm64__) && __has_cpp_attribute(clang::ptrauth_vtable_pointer)
#      if __has_feature(ptrauth_type_info_discriminated_vtable_pointer)
#        define _LIBCPP_TYPE_INFO_VTABLE_POINTER_AUTH                                                                  \
          [[clang::ptrauth_vtable_pointer(process_independent, address_discrimination, type_discrimination)]]
#      else
#        define _LIBCPP_TYPE_INFO_VTABLE_POINTER_AUTH                                                                  \
          [[clang::ptrauth_vtable_pointer(process_independent, no_address_discrimination, no_extra_discrimination)]]
#      endif
#    else
#      define _LIBCPP_TYPE_INFO_VTABLE_POINTER_AUTH
#    endif
```

@ahmedbougacha I was unable to find any information about `ptrauth_type_info_discriminated_vtable_pointer` preprocessor feature in your branch (except its usage in include/typeinfo in libcxx). I also do not see any changes related to additional discrimination in initialization of `CXXTypeInfoVTablePointer` field of `class PointerAuthOptions`. It looks like there are no related changes in `ItaniumRTTIBuilder::BuildVTablePointer` as well. Please let me know if non-zero discrimination is actually supported on clang side for type info vtable pointers?

@ahmedbougacha @asl @ldionne I think there are 3 questions we need to answer to construct a condition everyone likes.

1. Do we want to check target architecture? If so, both `__arm64__` and `__aarch64__` should be checked. I'd prefer to have this check - even though it's probably redundant since other ptrauth-related checks are true only on aarch64, IMHO for those who don't know all the context it might be useful to see the architecture name and know that "OK, it's aarch64-specific stuff".

2. Do we want to check `ptrauth_calls` preprocessor feature enabled? I'd prefer to have this check - it's probably also redundant since `[[clang::ptrauth_vtable_pointer]]` attribute should have no effect w/o `ptrauth_calls` preprocessor feature, but, again, more verbosity might be useful for those who reads the code.

3. Do we want to allow type-based and/or address discrimination for type info vtable pointers? If so, what's the condition for that? Check against `__has_feature(ptrauth_type_info_discriminated_vtable_pointer)` like in @ahmedbougacha 's branch, or smth else?


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