ABI 兼容性标头/库交叉检查
我一直在寻找 ABI 交叉检查工具。现在我已经遇到了其他问题中建议的一些工具，例如在这些问题中：
现在，这并不完全是我想要做的 - 因为它们跟踪版本之间的 ABI 更改。
我想知道给定的项目源文件+库头文件和库.so文件，以及编译器版本（用于编译库和项目），是否可以交叉检查ABI的输出与编译的库匹配吗？
因此，它适用的情况是上游库提供了 libfoo.so 和 libfood.so。其中 food 的 ABI 略有不同（例如双精度而不是浮点数），但还没有到无法编译的程度。
- 是否有可能提出一个测试（可能不是防弹的）来表明编译后的可执行文件已链接到正确的库？
- 有没有工具可以做到这一点？
I have been looking around for an ABI cross-check tool. Now I have met some of the tools suggested in other questions, such as in these questions:
How to test binary compatibility automatically?
Static analysis tool to detect ABI breaks in C++
Now, this is not exactly what I am trying to do - as these track ABI changes between versions.
I was wondering that given project source files + library header file and library .so file, as well as a compiler version (which is used for compiling both the library and the project), is it possible to cross check that the output of the ABI matches the compiled library?
So, the situation that it would apply to, is if an upstream library shipped libfoo.so and libfood.so. Where food is a slightly different ABI, (say doubles instead of float), but not so far that it wont compile.
- Is it possible to come up with a test (possibly not bulletproof) that says that the compiled executable has linked against the correct lib?
- Are there tools that do this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果你假设你只有用 C 编码的 libfoo.so（没有它的头文件，你也应该有），那么就无法知道内部函数的签名，因为符号共享对象的表不包含任何类型信息（例如，除了传统观点之外，没有什么可以阻止库包含一个 malloc 函数，该函数将两个整数相加并返回它们的总和，而不是进行通常的堆分配） 。
因此
libfoo.so可能会被滥用。但是，通常在某些共享库中存在与符号关联的版本（您可以通过 dlvsym< 以编程方式查询该版本/a> 如果您dlopen-ed 一个库）。有一些方法可以生成版本。如果库是纯 C++，则符号会损坏，因此它们的编码包含它们的签名。
最佳实践是在库中包含一些返回库版本的函数。查看 glib 版本信息 函数作为一个很好的示例。
If you assume you have only
libfoo.socoded in C (without having its header files, which you should also have), there is no way to know e.g. the signature of the functions inside, because the symbol table of a shared object don't contain any typing information (e.g. nothing except conventional wisdom prevent a library to contain amallocfunction which adds two integers and return their sum, instead of doing the usual heap allocation).So the
libfoo.socan be abused. However, there are usually versions associated with symbols in some shared libraries (and you can query that programmatically thru dlvsym if youdlopen-ed a library). There is some way to generate the versions.If the library is pure C++, then symbols are mangled so their encoding contain their signature.
The best practice is to have some functions inside your library which return the version of the library. Look at glib version information functions for a good example.
似乎 ABI 合规性检查器 还支持检查应用程序是否暴露于任何两个库之间的更改。
It seems that the ABI compliance checker also supports checking an application for its exposure to any changes between two libraries.