Using vtable structs in class datatypes

[kevinhartman]

I'm a bit confused about how vtables and class datatypes should be organized. For example, suppose we have a class structure like this:

class Base {
 public:
  virtual void A() {}
  int a = 0;
};

class Derived : public Base {
 public:
  virtual void B() {}
  int b = 0;
};

class DerivedDerived : public Derived {
 public:
  virtual void C() {}
  int c = 0;
};

Let's assume the compiler generated one vtable for each of these classes. How should this be modeled with vtables and data types in Ghidra?

I would expect that:

• DerivedDerived would start with a Derived at offset 0, followed by field c.
• Derived would start with a Base at offset 0, followed by field b.
• Base would start with some vtable pointer at offset 0, followed by field a.

But, which vtable type should Base point to? If it points to Base's vtable, the decompiler won't show methods B or C when using the derived types. I suppose in this simple case, I could point to DerivedDerived's vtable, but that feels wrong.

Maybe this is a case for unions, or there's some fancy auto storage feature? What's the right procedure?

I realize this is probably a general question for Ghidra, but it seems more relevant to this project and its users.

Thanks!

[astrelsky]

In reality the _vptr would point to the DerivedDerived vtable. Union support in the decompiler was added in 10.2_Dev and I have begun using them in the dev branch. With unions I am currently modeling it as follows:

struct Base {

    struct {
        void (*A)();
    } *_vptr;

    int a = 0;
};

struct Derived {

    union {
        struct {
            void (*A)(); // I think Derived's vtable would have it too.
            void (*B)();
        } *_vptr;
        Base Base;
    } super;
    int b = 0;
};


struct DerivedDerived {

    union {
        struct {
            void (*A)();
            void (*B)();
            void (*C)();
        } *_vptr;
        Derived Derived;
    } super;
    int c = 0;
};

Of course this can be infinitely more complex and have virtual bases but this is the general idea.

Also it's actually not valid C++ to have a non standard layout type in a union (I forget the correct term but no types with virtual methods or bases). At this point I don't really care because it helps show what is going on in the decompiled code.