在调试信息压缩标志的各种组合下，汇编器和链接器之间的压缩调试信息如何流动？

Posted 2023-03-06

【中文标题】在调试信息压缩标志的各种组合下，汇编器和链接器之间的压缩调试信息如何流动？

【英文标题】：How does compressed debug info flow between the assembler and linker under various combinations of debug info compression flags?

【发布时间】：2020-04-08 22:12:15

【问题描述】：

在 gcc 和 binutils 中有许多关于调试信息压缩的标志。在这里，我对标准 C++ 项目中以下四个标志之间的相互作用感兴趣，该项目使用编译器创建许多目标文件，然后使用编译器驱动将目标文件组合成各种最终二进制文件的链接步骤：

-Wa,--compress-debug-sections=zlib-gabi -Wa,--nocompress-debug-sections -Wl,--compress-debug-sections=zlib-gabi -Wl,--compress-debug-sections=none

所以，我们可以想象四种可能性。我们已经在汇编器中未压缩或使用-Wa,--compress-debug-sections=zlib-gabi 编译目标文件，并且我们已将目标文件链接到在链接器中未压缩或启用-Wl,--compress-debug-sections=zlib-gabi 的二进制文件中。

用于编译的-Wa,--nocompress-debug-sections 和-Wl,--compress-debug-sections=none 的组合是无趣的。大概不会发生任何压缩。

接下来的两个组合更有趣：

-Wa,--compress-debug-sections=zlib-gabi 用于汇编器，-Wl,--compress-debug-sections=none 用于链接器，链接器似乎需要花时间从每个目标文件中解压缩调试信息，然后再合并它并发出新的未压缩调试信息部分用于最终的二进制文件。

-Wa,--nocompress-debug-sections 用于汇编器，-Wl,--compress-debug-sections=zlib-gabi 用于链接器，显然汇编器不会花时间压缩目标文件的调试信息，而链接器会花时间压缩最终文件合并调试信息部分。

我对这两种情况的假设和理解大多正确吗？如果不是，我误解了什么？

剩下最有趣的案例：

-Wa,--compress-debug-sections=zlib-gabi 连接到汇编器，-Wl,--compress-debug-sections=zlib-gabi 连接到链接器，这里会发生什么？如果我对上述情况的理解是正确的，我希望汇编器会做工作来压缩每个目标文件中的调试信息，然后链接器需要花时间解压缩它，然后进行合并，最后重新压缩合并调试信息部分。那是对的吗？或者链接器是否能够神奇地直接将目标文件中的压缩调试信息部分直接合并到链接步骤的最终压缩调试信息部分中，从而避免解压缩/重新压缩循环？

总的来说，我只是想了解在构建系统中我应该将这些标志默认为什么以获得最佳构建性能。我当然会做一些基准测试，但我也有兴趣了解这里的操作理论，因为它将帮助我了解围绕这些标志的任何构建基准测试结果。

【参考方案1】：

很遗憾，我对这个话题一无所知。 但是，我偶然发现以下内容可能会回答您问题的第一部分。

最近，-Wa,--compress-debug-sections 选项已可用。此选项将发送到链接器的目标文件的总大小减少了三分之一以上，因此调试信息现在占目标文件总大小的 70-80%。输出文件不受影响：链接器解压调试信息以便链接，并输出未压缩的结果（链接时有重新压缩调试信息的选项，但此步骤只会减小输出文件的大小改善链接时间或内存使用）。

发件人：https://gcc.gnu.org/wiki/DebugFission（部分：调试信息大小问题）

所以，看那句话，你对这两种情况的假设似乎是正确的：

-Wa,--compress-debug-sections=zlib-gabi 和 -Wl,--compress-debug-sections=none -Wa,--nocompress-debug-sections 和 -Wl,--compress-debug-sections=zlib-gabi