acm*_*acm 5 compression linker binutils
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
归档时间: |
|
查看次数: |
1512 次 |
最近记录: |