On Thu, Jan 18, 2024 at 4:04 AM Thiago Macieira wrote:

>
> 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?