打破带有 C++ 接口的 DSO/共享库的二进制向后兼容性并不难。也就是说,是否有一个静态分析工具可以帮助检测这种 ABI 中断,如果它有两组不同的头文件:DSO 的早期状态和当前状态的那些(也许还有 DSO)?欢迎免费和商业产品建议。
如果它还可以警告不良做法,例如 DSO 接口中的内联函数和默认函数参数,那就太好了。
打破带有 C++ 接口的 DSO/共享库的二进制向后兼容性并不难。也就是说,是否有一个静态分析工具可以帮助检测这种 ABI 中断,如果它有两组不同的头文件:DSO 的早期状态和当前状态的那些(也许还有 DSO)?欢迎免费和商业产品建议。
如果它还可以警告不良做法,例如 DSO 接口中的内联函数和默认函数参数,那就太好了。
abi-compliance-checker - 用于检查共享 C/C++ 库 (DSO) 的向后二进制/源代码级兼容性的工具:
用于检查 C/C++ 库的向后二进制和源代码级兼容性的工具。该工具检查新旧版本的头文件和共享库,并分析 API 和 ABI(ABI=API+编译器 ABI)中可能破坏二进制和/或源兼容性的更改:调用堆栈的更改、v-table 更改、删除的符号, 重命名字段等
icheck - C 接口 ABI/API 检查器:
用于静态检查 C 接口的 API 和 ABI 更改的工具。应该检测到所有可能导致 ABI 更改的类型声明更改以及大多数 API 更改。icheck 旨在与库一起使用,作为防止 ABI 漂移的一种方法。
shlib-compat - 带有符号版本控制的共享库的 ABI 兼容性检查器:
shlib-compat 使用 dwarf 调试符号来重新创建和比较导出符号的定义,包括函数参数和结构类型。
您也可能对linux 上游跟踪器和linux abi 跟踪器服务感兴趣。它们都由 abi-compliance-checker 工具提供支持。
我假设您熟悉本教程:Binary Compatibility Issues with C++,如果没有阅读它!
我听说过这个工具: http: //ispras.linuxbase.org/index.php/ABI_compliance_checker,但从未测试或使用过,所以没有意见。
您也可能对此感兴趣:使用 Boost 创建具有向后兼容 ABI 的库
我记得他们在工作中使用GCC XML来测试二进制兼容性。基本上它所做的是生成编译器对象树的 xml 表示。理论认为,如果 xml 是等价的,它们的二进制兼容性就得到了维护。
唯一安全的方法是使用 C 接口导出库。C++ 库仅与您用来编译它的一个编译器兼容。
我们的C++ Smart Differencer工具比较两个源文件并报告语言结构(标识符、表达式、语句等)和合理的编辑操作(插入、删除、移动、复制、替换标识符等)方面的差异。
它不直接回答 ABI 问题,但它提供的信息可能非常有用。另一个答案中讨论的一个示例是从struct {a,b}到struct {b,a}的返回类型更改。SmartDifferencer 会报告a已移动。(注意:常规 diff 工具会报告包含结构定义的行已更改,因此您会获得相同的信息,但 SmartDifference 也会忽略空格/布局和注释的更改,从而产生更少的概念噪音)。
这些工具都不会报告 typedef 定义的变化,它在另一个头文件中。但随后大概会比较所有涉及的头文件。如果您不想手动执行此操作,则使用的任何工具都必须包含完整的 C++ 解析器、名称解析器,并且必须比较声明的等效性。另一张海报几乎提出了这个答案:比较 GCCXML 输出的等效性。我不确定这在实践中有多容易。它不能只是“文件的顺序是相同的 XML 吗?”。
ABI - 应用程序二进制接口归结为编译器将源代码转换为机器可识别指令的方式。在最终程序中,相同的源代码行可以转换为不同的字节流。
在源代码上运行的静态分析器将无法预测编译器将如何翻译它。该决定是在编译器编码或设置中做出的。所以我不相信在这种情况下静态分析器会对你有所帮助。