Page MenuHomePhabricator

[libcxxabi] Add macro for changing functions to support the relative vtables ABI
ClosedPublic

Authored by leonardchan on Apr 6 2020, 4:21 PM.

Details

Summary

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.

Diff Detail

Event Timeline

leonardchan created this revision.Apr 6 2020, 4:21 PM
Herald added a reviewer: Restricted Project. · View Herald TranscriptApr 6 2020, 4:21 PM
leonardchan planned changes to this revision.Apr 6 2020, 4:21 PM

Marking WIP for now since (I think for testing), this will require some separate clang changes first.

leonardchan retitled this revision from [WIP][libcxxabi] Add macro for changing functions to support the relative vtables ABI to [libcxxabi] Add macro for changing functions to support the relative vtables ABI.
leonardchan edited the summary of this revision. (Show Details)
leonardchan removed 1 blocking reviewer(s): Restricted Project.

Ok. Ready for review!

Herald added 1 blocking reviewer(s): Restricted Project. · View Herald TranscriptAug 12 2020, 5:46 PM

Long-term, I think we want this to be keyed entirely on a compiler predefine and not chosen in cmake.

ldionne requested changes to this revision.Aug 13 2020, 5:44 AM

Long-term, I think we want this to be keyed entirely on a compiler predefine and not chosen in cmake.

Actually, I'd like to use that approach now. @leonardchan is that possible?

This revision now requires changes to proceed.Aug 13 2020, 5:44 AM

Long-term, I think we want this to be keyed entirely on a compiler predefine and not chosen in cmake.

Actually, I'd like to use that approach now. @leonardchan is that possible?

Can do. Something like D85924?

Long-term, I think we want this to be keyed entirely on a compiler predefine and not chosen in cmake.

Actually, I'd like to use that approach now. @leonardchan is that possible?

Can do. Something like D85924?

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.

leonardchan edited the summary of this revision. (Show Details)

Update to use the __has_feature(cxx_abi_relative_vtable) macro to check how we should find the dynamic_type.

mcgrathr added inline comments.Oct 8 2020, 4:27 PM
libcxxabi/src/private_typeinfo.cpp
647

I think this should be const uint32_t* ... and <const uint32_t* const*>.

649

This should also be pointer to const.

leonardchan marked 2 inline comments as done.

Update with more consts and clang-formated.

*ping* Any more comments on this patch?

ldionne added inline comments.Nov 19 2020, 11:04 AM
libcxxabi/src/private_typeinfo.cpp
644

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.

645

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?

leonardchan marked an inline comment as done.
leonardchan added inline comments.
libcxxabi/src/private_typeinfo.cpp
644

The latter, where it's turned on.

645

Thanks for catching this. It took me some time to check and assert what these values should be. Updated to just load 32-bit ints instead of ptrdiff_t.

ldionne requested changes to this revision.Nov 25 2020, 12:08 PM
ldionne added inline comments.
libcxxabi/src/private_typeinfo.cpp
654

Can you avoid changing the formatting of this piece of code to make it clear it's unchanged?

This revision now requires changes to proceed.Nov 25 2020, 12:08 PM
leonardchan marked 2 inline comments as done.

Removed formatting for existing code.

ldionne accepted this revision.Nov 26 2020, 9:18 AM
This revision is now accepted and ready to land.Nov 26 2020, 9:18 AM