================ @@ -300,7 +300,7 @@ class _LIBCPP_EXPORTED_FROM_ABI _LIBCPP_TYPE_INFO_VTABLE_POINTER_AUTH type_info protected: typedef __type_info_implementations::__impl __impl; - __impl::__type_name_t __type_name; + _LIBCPP_NO_PFP __impl::__type_name_t __type_name; ---------------- pcc wrote:
> Whether there is a "real benefit" is subjective, though. Not having to think > about PFP in libc++abi is a very real (and valuable) benefit from my > perspective (but perhaps not from someone else's perspective). Sure, but it seems like a relatively small benefit. It lets us save changing 4 lines of code in libc++ and libc++abi which seem to need very little maintenance (because they reflect ABI). According to `git blame` these lines were last changed in libc++abi 10 years ago, and in libc++ 6 years ago ignoring a formatting change. Whereas on the Clang side I think we would need somewhere around 100 lines of code to generate initializers for these fields, which will need to be maintained as Clang's API develops (and will need to be reimplemented in CIR, etc). Generating these initializers will need a separate code path because these RTTI types are not defined in the Clang AST like other types are. > Can you explain why that's the case? Where/why is the name of the field > relevant when PFP is enabled? That's probably obvious when you know PFP but > I'm not seeing it. That's because the field names are encoded into names of deactivation symbols (https://discourse.llvm.org/t/rfc-deactivation-symbols/85556) as well as being hashed into the discriminator used to sign pointers. In principle, we could encode field offsets instead of names, but I've frequently found the explicit names useful for debugging. > IIUC, you are implying that right now, we could link both a PFP libc++ and a > non-PFP libc++ into the same program without issues because they use a > different inline namespace, and libc++abi.dylib doesn't have an inline > namespace. So IIUC what you're saying is that you could use pfp-libc++.dylib, > nonpfp-libc++.dylib and libc++abi.dylib (which would be PFP-agnostic) into > the same program. Is that the idea? My first reaction to this is that it > seems like a very fragile setup. Yes, that's pretty much it (except that PFP doesn't support dynamic linking, so it would be .a instead of .dylib). As I mentioned earlier, we have no need for this. But maybe if we can avoid obvious breakage to this setup, that may be worthwhile in case someone needs it in the future (at which point it may be too late to fix it because the ABI will be set in stone). https://github.com/llvm/llvm-project/pull/151651 _______________________________________________ llvm-branch-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
