Home > other >  Implications of Derived class having a different ABI, than Base class?
Implications of Derived class having a different ABI, than Base class?

Time:09-10

While debugging with gdb, printing the vtable yields something like the following:

(gdb) info vtbl *object
vtable for 'my_namespace_B::MyDerivedObject' @ 0x555555690bf0 (subobject @ 0x5555556ab710):
[0]: 0x55555559ff42 <my_namespace_A::MyBaseObject::function1[abi:cxx11]() const>
[1]: 0x5555555a016c <my_namespace_A::MyBaseObject::function2[abi:cxx11]() const>
[2]: 0x5555555a030a <my_namespace_A::MyBaseObject::function3() const>
[5]: 0x5555555a47f8 <my_namespace_B::MyDerivedObject::~MyDerivedObject()>
[6]: 0x5555555a4846 <my_namespace_B::MyDerivedObject::~MyDerivedObject()>
[7]: 0x5555555a0a80 <my_namespace_B::MyDerivedObject::fun1(bool)>

What does the [abi:cxx11] part mean? I understand that this should mean that that part of the code was compiled using cxx11 features.

  • is this understanding even correct?
  • What implications might this have?
  • Could this be the reason why calling the virtual function fun1 from within BaseObject::nonVirtualMemberFunction yields undefined behavior?

CodePudding user response:

This is the abi_tag attribute, either applied directly to your function or the return type is tagged.

Most likely your functions just return std::string, which libstdc tags with abi_tag("cxx11") so that code compiled with the old C 03 copy-on-write strings doesn't link to modern code and silently break.

There are no "visible" differences, just that if you compiled something with the old string ABI it wouldn't link. It should work the same as any other virtual function.

  • Related