rjmccall added a comment. I'm not sure if the AST-level v-table layout abstraction really cares about these differences. I don't think it vends byte offsets into the v-table, just slot indices (i.e. word offsets).
================ Comment at: clang/include/clang/AST/VTableBuilder.h:380 + /// other structs/functions. + Relative, + }; ---------------- The only "struct" pointed to by the v-table is the `type_info` object. How are you planning to handle that? The standard ABI makes the `type_info` a vague-linkage symbol in most cases, so you won't be able to have a direct relative reference to it. If you adopt the Apple ARM64 modification for `type_info` equality, you can rely on the `type_info` being defined within the same linkage unit unless the v-table is being emitted as an optimization for a type defined with a key function in a different linkage unit. You could handle that by making this an "inidirectable" relative reference, where it's either a direct relative reference or a relative reference to a GOT entry, as specified by the low bit in the reference. But you need *some* solution for this. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D77592/new/ https://reviews.llvm.org/D77592 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
