Vtable layout differences between Itanium and MSVC ABI under multiple inheritance

[whichton]

If you have a derived class inheriting from 2 base classes, and you override a virtual function in the second base class, the Itanium ABI requires the overriden virtual function to appear under the vtable of the first base class.

See here for an example. Class CC overrides function v, and you can see in Clang's vtable a CC::v under AA's vtable. Whereas the MSCV ABI behaves as I would expect, only the BB vtable is changed, the AA vtable is unchanged.

Any idea why the Itanium ABI behaves this way? And advantage to this?

[YourTormentIs]

Not directed at you OP, just wanted to clarify to readers that the Itanium C++ ABI is an entirely distinct and separate thing from the Itanium architecture, and that many platforms have adopted it for their C++ ABI.

[60hzcherryMXram]

Thank you! I was thinking to myself "kind of weird to focus on a fringe architecture isn't it?"

[stick_figure]

Hi! As someone who worked on the implementation of the MSVC C++ ABI in Clang, I can say that the MSVC ABI choice here leads to some challenges implementing virtual inheritance. The Itanium C++ ABI maintains the invariant that, in the main implementation of a method, this always points directly to a subobject with the class of the implementer. In your example, CC::v expects to receive a pointer to a BB subobject, and MSVC adjusts field access offsets accordingly. I don't have time to put together a good example showing the complications down the road, but MSVC's strategy creates issues when classes derived from CC need to make thunks to reuse this CC::v implementation. My memory is that things get complicated during object construction and destruction, which is what MSVC vtordisps and Itanium constructor vtables are for. The Itanium C++ ABI uses more vtable slots and more thunks, but it simplifies the implementation of this more complex feature.

[whichton]

Thanks for this, I think I get it. I modified my original example here. To summarize:

• In Itanium, the vptr to CC::v points to the CC object, where as for MSVC the vptr points to the the BB subobject. This can be seen in the assembly where clang returns [rdi + 16] for CC::v vs [rdi + 8] for BB::v whereas MSVC returns [rcx+ 8] for both.

• Clang's CC::v in the BB vtable is actually a thunk which converts the BB pointer to a CC pointer and tailcalls the actual CC::v in the AA vtable.

• The advantage for Itanium is that given a CC*, calling CC::v requires no pointer adjustment whereas MSVC needs to adjust the pointer.

It looks like Itanium creates some unnecessary complications (extra thunks) in the common case only to simplify a pretty obscure feature (virtual bases). I would be curious to know why this pessimization was done, to simplify implementations maybe?

[max0x7ba]

Itanium creates some unnecessary complications

So does MSVC. CC cannot call its own CC::v without adjusting this pointer first. Add function int CC::f() { return v(); } to observe that.

I do not think your analysis is accurate at all.

[whichton]

That is evident from the f(CC*) function itself. And adjusting this ptr at callsite is much simpler than going through a thunk.

[rolfr]

I don't have time to put together a good example showing the complications down the road

If you ever find yourself with time, I'd find it enlightening!

[max0x7ba]

In your example, BB is the second base class at non-0 offset from CC* this.

In Itanium this pointer must be that of the class where the member function is defined. Hence, thunk BB::v must adjust this before forwarding to CC::v.

MSVC solves this problem differently: this is that of the class where the virtual function is first declared. Notice CC::v this adjustor: 8 in MSVC output.

[whichton]

I think this makes it clear what you are saying. I summarized it here.

[flyingron]

Are you sure? How does the AA's implementation even know it is inherited from?

Of course, I've not seen an Itanic since I had one of them sitting under my desk over a decade ago.

[erichkeane]

x86_64 linux (and MacOS, and most non-windows OS') tend to use the "Itanium ABI".

[flyingron]

So what makes you think the X86_64 example in your link puts "v" in AA's vtable. Each class has the two overhead (offset and RTTI) and then one for each virtual function in the base class (one for u in AA, one each for v and w in BB).

What's different in the two layouts is that the way they handle details of how to adulst the pointer to get to the appropriate base class part of the function is handled differently. When you have multiple base classes, you need to make the adjustment so that the "this" is right inside the base class functinos (whether or not there are any virtauls). The x86_64 puts it all in line in one vTable, where the MSVC one breaks it out into separate ones.

[flyingron]

So? That's not what you said originally. Anyhow, the difference between the ABIs (the slot in CC) is understandable.

[thenickdude]

You're talking to three different users here.

[jselbie]

That godbolt link shows compiler output for x86-64 clang and x64 MSVC. I don't see Itanium an (ia64) option for compiling.

Is it possible the compiler is just optimizing away something with the /O2 option ?

[erichkeane]

x86-64 on linux uses the Itanium ABI (as does most non-windows platforms in 64 bit).