On Sat, Feb 17, 2024 at 8:50 PM Thiago Macieira wrote:
>
> > This won't change the size, alignment or layout of an 'IDevice' object --
> > it will just extend the vtable by two pointers. This isn't an ABI break.
>
> It is for any class deriving from IDevice that wasn't recompiled with the new
> definition. Your original problem had a narrow definition:


Oh yes of course . . . if we were to have:

    class IKeyboard : public IDevice { virtual bool
GetKeyboardState(void) = 0; };

Then the offset of 'GetKeyboardState' in IKeyboard's vtable would
increase if more virtual methods were to be added to IDevice.

I wonder could we somehow mark a class as 'extensible' to indicate
that the vtables should be laid out in such as way as to allow for the
extending of classes in the future? For example, the vtable for
IKeyboard could instead be:

    -------------------------------
    | address of IDevice vtable |
    -------------------------------
    | address of GetKeyboardState |
    -------------------------------

So then we could add more virtual functions to IDevice without it
affecting the offset of 'GetKeyboardState'.

When it comes to the linking stage, there will be multiple definitions
of "_ZTV7IDevice", and they will be of different sizes -- however all
of them will be weak symbols and so the linker will choose the biggest
of them (or at least that's how the GNU bfd linker works)