在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到链接器，这里会发生什么？如果我对上述情况的理解是正确的，我希望汇编程序能够压缩每个对象文件中的调试信息，然后链接器需要花时间对其进行解压缩，然后进行合并，最后重新压缩合并的调试信息部分。这是正确的吗？或者，链接器是否能够神奇地将对象文件中的压缩调试信息部分直接合并到链接步骤的最终压缩调试信息中，从而避免解压缩/重新压缩周期
总的来说，我只是想了解在构建系统中应该将这些标志默认为什么，以获得最佳的构建性能。我当然会做一些基准测试，但我也有兴趣了解这里的操作理论，因为它将帮助我了解围绕这些标志的任何构建基准测试结果。
遗憾的是，我对这个话题并不了解
然而，我偶然发现了以下内容，这些内容可能会回答您问题的第一部分。
最近，-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