为什么函数在ELF中的其他共享库的长度信息?

Our project (C++, Linux, gcc, PowerPC) consists of several shared libraries. When releasing a new version of the package, only those libs should change whose source code was actually affected. With "change" I mean absolute binary identity (the checksum over the file is compared. Different checksum -> different version according to the policy). (I should mention that the whole project is always built at once, no matter if any code has changed or not per library).

我们的项目(c++、Linux、gcc、PowerPC)由几个共享库组成。当发布包的新版本时，只有那些libs应该更改其源代码实际上受到了影响。使用“change”时，我指的是绝对二进制标识(对文件的校验和进行比较)。根据策略不同的校验和->版本)。(我要指出的是，无论每个库的代码是否更改，整个项目总是同时构建的)。

Usually this can by achieved by hiding private parts of the included Header files and not changing the public ones.

通常这可以通过隐藏包含的头文件的私有部分和不更改公共文件来实现。

However, there was a case where a mere delete was added to the destructor of a class TableManager (in the TableManager.cpp file!) of library libTableManager.so, and yet the binary/checksum of library libB.so (which uses class TableManager ) has changed.

然而，有这样一种情况:仅将删除添加到类TableManager的析构函数中(在TableManager中)。图书馆libTableManager的cpp文件!还有图书馆libB的二进制/校验和。所以(使用类TableManager)已经改变。

TableManager.h:

class TableManager 
{
public:
    TableManager();
    ~TableManager();
private:
    int* myPtr;
}

TableManager.cpp:

TableManager::~TableManager()
{
    doSomeCleanup();
    delete myPtr;     // this delete has been added
}

By inspecting libB.so with readelf --all libB.so, looking at the .dynsym section, it turned out that the length of all functions, even the dynamically used ones from other libraries, are stored in libB! It looks like this (length is the 668 in the 3rd column):

通过检查libB。还有readelf——所有的libB。所以，看一下。dynsym部分，发现所有函数的长度，甚至是其他库中动态使用的函数的长度，都存储在libB中!它看起来是这样的(长度是第3列的668):

527: 00000000 668 FUNC GLOBAL DEFAULT UND _ZN12TableManagerD1Ev

527: 00000000 668 FUNC全局默认值和_zn12tablemanager1ev

So my questions are:

所以我的问题是:

Why is the length of a function actually stored in the client lib? Wouldn't a start address be sufficient?
为什么函数的长度实际上存储在客户机lib中?起始地址不是就足够了吗?
Can this be suppressed somehow when compiling/linking of libB.so (kind of "stripping")? We would really like to reduce this degree of dependency...
当编译/链接libB时，这是否可以被抑制。(“剥离”)?我们真的想减少这种依赖程度……

2 个解决方案

#1

Bingo. It is actually kind of a "bug" in binutils which they found and fixed in 2008. The size information is actually not useful!

宾果。这实际上是binutils中的一个“bug”他们在2008年发现并修复了它。尺寸信息实际上是没有用的!

What Simon Baldwin wrote in the binutils mailing list describes exactly the problem ( emphases by me):

西蒙·鲍德温(Simon Baldwin - Baldwin)在binutils邮件列表中所写的内容准确地描述了这个问题(由我强调):

Currently, the size of an undefined ELF symbol is copied out of the object file or DSO that supplies the symbol, on linking. This size is unreliable, for example in the case of two DSOs, one linking to the other. The lower- level DSO could make an ABI-preserving change that alters the symbol size, with no hard requirement to rebuild the higher-level DSO. And if the higher- level DSO is rebuilt, tools that monitor file checksums will register a change due to the altered size of the undefined symbol, even though nothing else about the higher-level DSO has altered. This can lead to unnecessary and undesirable rebuild and change cascades in checksum-based systems.

目前，一个未定义的ELF符号的大小被复制到对象文件或DSO中，该文件在链接时提供该符号。这种大小是不可靠的，例如对于两个DSOs，一个连接另一个。较低级别的DSO可以做一个改变符号大小的保用更改，并没有硬性要求重新构建更高级别的DSO。如果重新构建了更高级别的DSO，那么监视文件校验和的工具将会由于未定义符号的大小的改变而注册一个更改，尽管关于更高级别的DSO没有任何其他更改。这可能导致不必要的和不受欢迎的重建，并在基于校验的系统中改变级联。

We have the problem with an older system (binutils 2.16). I compared it with version 2.20 on the desktop system and - voilà - the lengths of shared global symbols were 0:

我们有一个老系统的问题(binutils 2.16)。我将它与桌面系统上的2.20版本进行了比较——瞧——共享全局符号的长度为0:

157: 00000000     0 FUNC    GLOBAL DEFAULT  UND _ZN12TableManagerD1Ev
158: 00000000     0 FUNC    GLOBAL DEFAULT  UND _ZNSs6assignERKSs@GLIBCXX_3.4 (2)
159: 00000000     0 FUNC    GLOBAL DEFAULT  UND sleep@GLIBC_2.0 (6)
160: 00000000     0 FUNC    GLOBAL DEFAULT  UND _ZN4Gpio11setErrorLEDENS_

So I compared both binutils source codes, and - voilà again - there is the fix which Alan suggested in the mailing list:

所以我比较了binutils的源代码，然后——瞧，还有艾伦在邮件列表中建议的修复:

Maybe we just apply the patch and recompile binutils since we need to stay with the olderish platform. Thanks for your patience.

也许我们只需要应用补丁并重新编译binutils，因为我们需要使用更老的平台。谢谢你的耐心。

2 个解决方案

#1

更多相关文章

随机推荐