Question

我正在阅读有关如何使用GCC的ld版本脚本在ELF共享库中对符号进行版本化的知识，并且我知道可以使用如下指令导出相同符号的不同版本： / p>

__asm__(".symver original_foo,foo@VERS_1.1");

如果函数的语义发生变化，这很有用，但是库仍然应该导出旧版本，以便使用该库的旧应用程序仍可以使用较新版本。

但对于C ++库，将导出符号vtable for MyClass。如果我稍后通过添加更多虚函数来更改类，除了新版本的vtable之外，我如何导出包含原始vtable符号的原始类？

编辑：我做了一个测试用例似乎通过将一个类的所有符号重命名为另一个类的符号来工作。这看起来像我希望的那样有效，但它能保证工作还是我幸运？代码如下：

EDIT2：我改变了类的名称（希望）不那么混乱，并将定义分成2个文件。

EDIT3：它似乎也适用于clang ++。我将澄清我要问的整体问题：

这种技术是否确保Linux上C ++共享库中的类的二进制向后兼容性，而不管虚函数的差异如何？如果没有，为什么不呢？（一个反例会很棒）。

libtest.h：

struct Test {
    virtual void f1();
    virtual void doNewThing();
    virtual void f2();
    virtual void doThing();
    virtual void f3();
    virtual ~Test();
};

libtest_old.h：

// This header would have been libtest.h when test0 was theoretically developed.

struct Test {
    virtual void f3();
    virtual void f1();
    virtual void doThing();
    virtual void f2();
    virtual ~Test();
};

libtest.cpp：

#include "libtest.h"
#include <cstdio>

struct OldTest {
    virtual void f3();
    virtual void f1();
    virtual void doThing();
    virtual void f2();
    virtual ~OldTest();
};

__asm__(".symver _ZN7OldTestD1Ev,_ZN4TestD1Ev@LIB_0");
__asm__(".symver _ZN7OldTestD0Ev,_ZN4TestD0Ev@LIB_0");
__asm__(".symver _ZN7OldTest7doThingEv,_ZN4Test7doThingEv@LIB_0");
__asm__(".symver _ZN7OldTestD2Ev,_ZN4TestD2Ev@LIB_0");
__asm__(".symver _ZTI7OldTest,_ZTI4Test@LIB_0");
__asm__(".symver _ZTV7OldTest,_ZTV4Test@LIB_0");
__asm__(".symver _ZN7OldTest2f1Ev,_ZN4Test2f1Ev@LIB_0");
__asm__(".symver _ZN7OldTest2f2Ev,_ZN4Test2f2Ev@LIB_0");
__asm__(".symver _ZN7OldTest2f3Ev,_ZN4Test2f3Ev@LIB_0");

void OldTest::doThing(){
    puts("OldTest doThing");
}
void OldTest::f1(){
    puts("OldTest f1");
}
void OldTest::f2(){
    puts("OldTest f2");
}
void OldTest::f3(){
    puts("OldTest f3");
}
OldTest::~OldTest(){

}

void Test::doThing(){
    puts("New Test doThing from Lib1");
}
void Test::f1(){
    puts("New f1");
}
void Test::f2(){
    puts("New f2");
}
void Test::f3(){
    puts("New f3");
}
void Test::doNewThing(){
    puts("Test doNewThing, this wasn't in LIB0!");
}
Test::~Test(){

}

libtest.map：

LIB_0 {
global:
    extern "C++" {
        Test::doThing*;
        Test::f*;
        Test::Test*;
        Test::?Test*;
        typeinfo?for?Test*;
        vtable?for?Test*
    };
local:
    extern "C++" {
        *OldTest*;
        OldTest::*;
    };
};

LIB_1 {
global:
    extern "C++" {
        Test::doThing*;
        Test::doNewThing*;
        Test::f*;
        Test::Test*;
        Test::?Test*;
        typeinfo?for?Test*;
        vtable?for?Test*
    };
} LIB_0;

生成文件：

all: libtest.so.0 test0 test1

libtest.so.0: libtest.cpp libtest.h libtest.map
    g++ -fPIC -Wl,-s -Wl,--version-script=libtest.map libtest.cpp -shared -Wl,-soname,libtest.so.0 -o libtest.so.0

test0: test0.cpp libtest.so.0
    g++ test0.cpp -o test0 ./libtest.so.0

test1: test1.cpp libtest.so.0
    g++ test1.cpp -o test1 ./libtest.so.0

test0.cpp：

#include "libtest_old.h"
#include <cstdio>

// in a real-world scenario, these symvers would not be present and this file
// would include libtest.h which would be what libtest_old.h is now.

__asm__(".symver _ZN4TestD1Ev,_ZN4TestD1Ev@LIB_0");
__asm__(".symver _ZN4TestD0Ev,_ZN4TestD0Ev@LIB_0");
__asm__(".symver _ZN4Test7doThingEv,_ZN4Test7doThingEv@LIB_0");
__asm__(".symver _ZN4Test2f1Ev,_ZN4Test2f1Ev@LIB_0");
__asm__(".symver _ZN4Test2f2Ev,_ZN4Test2f2Ev@LIB_0");
__asm__(".symver _ZN4Test2f3Ev,_ZN4Test2f3Ev@LIB_0");
__asm__(".symver _ZN4TestD2Ev,_ZN4TestD2Ev@LIB_0");
__asm__(".symver _ZTI4Test,_ZTI4Test@LIB_0");
__asm__(".symver _ZTV4Test,_ZTV4Test@LIB_0");

struct MyClass : public Test {
    virtual void test(){
        puts("Old Test func");
    }
    virtual void doThing(){
        Test::doThing();
        puts("Override of Old Test::doThing");
    }
};

int main(void){
    MyClass* mc = new MyClass();

    mc->f1();
    mc->f2();
    mc->f3();
    mc->doThing();
    mc->test();

    delete mc;

    return 0;
}

test1.cpp：

#include "libtest.h"
#include <cstdio>

struct MyClass : public Test {
    virtual void doThing(){
        Test::doThing();
        puts("Override of New Test::doThing");
    }
    virtual void test(){
        puts("New Test func");
    }
};

int main(void){
    MyClass* mc = new MyClass();

    mc->f1();
    mc->f2();
    mc->f3();
    mc->doThing();
    mc->doNewThing();
    mc->test();

    delete mc;

    return 0;
}

Answer 1

vtable符号和/或版本对于API和ABI都非常不重要。重要的是哪个vtable索引具有哪种语义。 vtable的名称和/或版本无关紧要。

通过使用一些轻量级运行时机制来检索特定接口的特定版本，可以实现向后兼容性。假设你有：

class MyThing: public VersionedInterface {...}; // V1
class MyThingV1: public MyThing {...};
class MyThingV2: public MyThingV1 {...};

您可能有一些功能来创建MyThings：

VersionedInterface *createMyThing();

这个VersionedInterface然后您需要询问您想要的界面版本（您的代码理解）：

// Old code will ask for MyThing:
VersionedInterface *vi = createMyThing();    
MyThing *myThing = static_cast<MyThing*>(vi->getInterface("MyThing"));

// New code may ask for MyThingV2:
VersionedInterface *vi = createMyThing();    
MyThingV2 *myThing = static_cast<MyThingV2*>(vi->getInterface("MyThingV2"));
// New code may or may not get the newer interface:
if (!myThing) 
{
    // We did not get the interface version we wanted.
    // We can either consciously fall back to an older version or simply fail.
    ...
}

班级VersionedInterface只提供getInterface()功能：

class VersionedInterface
{
public:
    virtual ~VersionedInterface() {}
    virtual VersionedInterface *getInterface(const char *interfaceName) = 0;    
};

这种方法的优点是它允许以干净和便携的方式对vtable进行任意更改（重新排序功能，插入和删除功能，更改功能原型）。

您可以将getInterface()函数扩展为也接受数字版本，实际上您也可以使用它来检索对象的其他接口。

您可以稍后在不破坏现有二进制代码的情况下向对象添加接口。这是主要优势。当然，获取接口的样板代码的成本。当然，维护同一界面的多个版本也有其自身的成本。应该充分考虑这项努力是否值得。

GNU LD符号版本控制＆amp; C ++二进制向后兼容性

1 个答案: