调试二进制文件:如何转储每个符号来自哪个 .a/.o?
我有一个启用调试的二进制文件、与其静态链接的 .a 文件的集合以及所有内容的源代码。
如何获得可解析的转储,其中列出最终可执行二进制文件中的每个符号名称,以及它来自哪个 .a 和 .o? (如果可能的话,加上原始的 .c/.cpp 文件。)
库中有一系列交叉依赖项、循环依赖项,甚至还有一些多重定义的符号,我正在尝试根据最终目标来映射这些符号重新创建构建系统。不知何故,旧的构建系统设法将所有内容链接在一起。 (我认为更多的是偶然而不是设计......)
到目前为止,我已经尝试了 nm
的各种调用,但似乎无法完全获取这些数据。也许 nm 是错误的工具。
I've got a debug-enabled binary, the collection of .a files it was statically linked with, and the source for everything.
How can I get a parse-able dump that lists each symbol name in the final executable binary, and which .a and .o it came from? (Plus the original .c/.cpp file, if possible.)
There are a series of cross-dependencies, circular-dependencies, and even a few multiple defined symbols in the libraries that I'm trying to map out with the eventual goal to recreate the build system. Somehow the old build system managed to get everything linked together. (More by accident than by design i think...)
So far, I've tried various invocations of nm
but can't quite seem to get this data. Perhaps nm
is the wrong tool.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
当最终的二进制文件被链接时,来自
.o
或.a
的符号的信息就会丢失。由于您有可用的调试信息,因此您可以知道每个符号的来源,这可能会帮助您重建丢失的信息(或不:如果
foo.c
被编译为foo1.o
、foo2.o
和foo3.o
(例如使用不同的-DFOO=1
等标志),然后填充到不同的归档库中,那么就没有简单的方法来判断哪个对象贡献了希望您的旧构建系统没有那么糟糕,
现在您有足够的信息将大多数符号映射到它们来自的对象。名称与目标文件名不匹配,您必须手动解决这些问题。
By the time final binary is linked, the info on which symbol came from which
.o
or.a
is lost.Since you have the debug info available, you can know the source of each symbol, and that may help you reconstruct the lost info (or not: if
foo.c
is compiled intofoo1.o
,foo2.o
andfoo3.o
(e.g. with different-DFOO=1
, etc. flags), and then stuffed into different archive libraries, then there is no easy way to tell which object contributed the symbol to the final binary. Hopefully your old build system was not that bad.So,
Now you have enough info to map majority of symbols to the objects they came from. There will probably be <= 10% of sources where source file name doesn't match object file name. These you'd have to resolve by hand.