一个elf文件中的".debug_info"部分是什么?

6
我有一个elf文件,使用elfparser分析mapfile和elf时,发现有一个名为.Debug_info的部分,占用了最大的内存。
我正在为xtensa DSP编译,使用xt-xc++,我没有使用-g选项,并给出了-o2优化级别。

enter image description here

是否可能在发布版本中删除这个?


不知道那个编译器,但这重要吗?通常有一种 objcopy 后构建步骤来创建特定于程序员的二进制文件,应该会丢弃那些部分。 - Trass3r
1
你尝试使用过-g0吗?或在ld中添加--gc-sections参数?无论如何,通常可以通过-s命令或strip工具来完成。 - Dan M.
我无法使用strip命令,因为它会移除完整的符号表。我需要在这个二进制文件上使用nm命令。 - thomachan
2
你看过这个吗?:调试器是如何工作的:第三部分 - 调试信息 - Scheff's Cat
1
@thomachan 阅读strip的手册页。它有各种选项,可以让您决定要剥离什么,包括仅剥离调试信息。 - David Schwartz
显示剩余2条评论
1个回答

7

有一个名为.debug_info的部分,它占用了最大的内存。

请注意,这个部分没有SHF_ALLOC标志,因此在运行时不会占用任何RAM(它只会占用文件系统中的空间)。当然,如果您使用ramdisk,那么这个部分最终仍会花费您的RAM。

是的:所有.debug*部分在运行时都不必要,所有这些部分都可以安全地剥离。

很可能你从你链接的库中得到了.debug_*部分,而不是来自你自己的代码。当库被编译时,-g已经存在,因此使用-g0进行构建没有任何效果。

令人惊讶的是,-s没有起作用,但也许你的编译器对这个标志的解释不同。

无论如何,你应该使用strip --strip-debug来摆脱.debug_*部分(注意:这不会删除符号表)。

最佳实践实际上是使用完整的调试信息(-g)编译所有代码,保存完整的调试二进制文件以进行事后分析,使用strip --strip-debug制作发布二进制文件,并使用该二进制文件进行实际分发。

如果/当发布二进制文件崩溃并留下核心转储时,拥有(保存的)完整调试完全匹配的二进制文件可以极大地改善您可以进行的事后分析。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接