Under the relative vtables ABI, __dynamic_cast will not work since it assumes the vtable pointer is 2 ptrdiff_ts away from the start of the vtable (8-byte offset to top + 8-byte pointer to typeinfo) when it is actually 8 bytes away (4-byte offset to top + 4-byte offset to typeinfo). This adjusts the logic under __dynamic_cast to support this ABI when it's used.
Details
- Reviewers
ldionne howard.hinnant mcgrathr - Group Reviewers
Restricted Project - Commits
- rG61aec69a65de: [libcxxabi] Add macro for changing functions to support the relative vtables ABI
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Marking WIP for now since (I think for testing), this will require some separate clang changes first.
Long-term, I think we want this to be keyed entirely on a compiler predefine and not chosen in cmake.
Yeah, something like that. I'm not a big fan of the name of the macro, but that's a different story to be discussed in D85924.
Update to use the __has_feature(cxx_abi_relative_vtable) macro to check how we should find the dynamic_type.
libcxxabi/src/private_typeinfo.cpp | ||
---|---|---|
618–622 | Just to be clear, is this enabled whenever the compiler *supports* the feature, or whenever the feature is actually turned on? The former would be incorrect, because any sufficiently recent Clang would take that code path. The latter is what we want. | |
623 | Are you certain this is the only place where code needs changing? For example we seem to extract the vtable in __base_class_type_info::search_above_dst and other functions -- don't they need to be changed too? |
libcxxabi/src/private_typeinfo.cpp | ||
---|---|---|
632 | Can you avoid changing the formatting of this piece of code to make it clear it's unchanged? |
I think this should be const uint32_t* ... and <const uint32_t* const*>.