================
@@ -1056,12 +1056,18 @@ class ConstantPtrAuth final : public Constant {
return !getAddrDiscriminator()->isNullValue();
}
- /// A constant value for the address discriminator which has special
- /// significance to ctors/dtors lowering. Regular address discrimination
can't
- /// be applied for them since uses of llvm.global_{c|d}tors are disallowed
- /// (see Verifier::visitGlobalVariable) and we can't emit getelementptr
- /// expressions referencing these special arrays.
- enum { AddrDiscriminator_CtorsDtors = 1 };
+ /// Constant values for the address discriminator which have special
+ /// significance to lowering in some contexts.
+ /// - For ctors/dtors, regular address discrimination can't
+ /// be applied for them since uses of llvm.global_{c|d}tors are disallowed
+ /// (see Verifier::visitGlobalVariable) and we can't emit getelementptr
+ /// expressions referencing these special arrays.
+ /// - For vtable pointers of std::type_info and classes derived from it,
+ /// we do not know the storage address when emitting ptrauth constant.
----------------
ahmedbougacha wrote:
Would it work to wire the storage address through
`ItaniumRTTIBuilder::BuildVTablePointer` from `BuildTypeInfo` ?
Beyond that, for static ctors, as I mentioned before, I still don't think this
should have ptrauth at the IR level, but rather should be a backend decision
made when encoding the IR representation of "a list of static ctors/dtors" to
some object file format encoding thereof. That would avoid needing this
address discriminator placeholder dance here. But I suppose that's a separate
problem.
https://github.com/llvm/llvm-project/pull/102199
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
