Change 1 can be skipped if the devirtualize function takes a pointer to the
object whose vtable you want to read. That's important because Change 1 is not
implementable, as none of the type_info objects today have a link back to the
vtable, and such a link cannot be added without an ABI incompatibility.
Are you sure it would be an ABI break?
Let's say that the type_info is stored in the ELF file inside the ."ro.data.rel" section, at offset 48 inside the section, and that its size is 72 bytes.
Well, when the compiler is writing the type_info to the object file, it can append two things onto the end of it:
First Thing: A predefined 128-Bit value (i.e. a UUID)
Second Thing: The address of the vtable
And so then the C++ function to get a vtable pointer from a type_info would be something like:
void const *get_polymorphic_facilitator(type_info const &ti)
{
__uint128_t n;
memcpy(&n, (char*)ti + 72u, 16u);
if ( n != my_predefined_uuid ) return nullptr;
void const *p;
memcpy(&p, (char*)ti + 72u + 16u, sizeof(void*) );
return p;
}
I don't think this would be an ABI break. Am I wrong?