如何在 Debian 系统上调试(慢速)链接器
在我的公司,我们的链接器有一个非常烦人的问题(ld 2.17)。 它在相对快速的系统(Core Duo,2GB RAM)上链接非常慢,我现在不知道如何解决这个问题。 编译一个比较大的项目大约需要五到十分钟(在我的Gentoo系统上链接大约需要5秒)。
就我个人而言,我认为这是一个巨大的生产力杀手,至少对我来说是这样。 我们尝试使用更新版本的 ld (2.19),但没有成功。 我在#debian on #freenode 上问过,但这个问题似乎很独特。 我在网上没有找到任何有关类似问题的信息。 仅当我们使用调试符号构建时才会发生这种情况。 我将 gcc 调试信息标志更改为 -g、-g3 和 -ggdb,但这也没有帮助。
所以我的问题是,如何分析和调试链接器? 我从来没有做过类似的事情,而且我找不到任何有关它的文档。 基本上任何合理的 gprof gmon.out 都会非常有帮助,因为我可以向 binutils 开发人员询问具体问题。 我只是完全忘记了这一点。
编辑:我们“修复”了在大多数系统上切换到 debian lenny 的问题。 感谢您的回答!
At my company we have a really annoying problem with our linker (ld 2.17). It links very very slow on a relatively fast system (Core Duo, 2GB Ram) and I don't really now how to fix this. It takes about five to ten minutes to compile a relatively big project (which takes about 5 seconds to link on my Gentoo system).
Personally i think it is a huge productivity killer, at least for me. We tried to use a more recent version of ld (2.19) but without any success. I asked in #debian on #freenode, but this problem seems to be very unique. I did not find any information about similar problems on the net. It only happens when we build with debug symbols. I changed the gcc debug-information flags to -g, -g3, and -ggdb, but that did not help either.
So my question is, how do you profile and debug a linker? I have never done anything like it, and I am unable to find any documentation about it. Basically any reasonable gprof gmon.out would be very helpful, as I could ask the binutils developers about a concrete problem. I am just completely oblivious about this.
Edit: We 'fixed' our problem switching to debian lenny on most systems. Thanks for the answers!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
您可以尝试使用 gold (
binutils-gold
) 而不是ld
。应该会更快。
以下是Wikipedia Gold(linker)的引用
gold 的作者 (Ian Lance Taylor) 发表了一篇关于链接器的(较长的)文章,其中他解释了他编写黄金的动机以及为什么大多数链接器都很慢。 如果您对链接器的内部工作原理感兴趣,那么这篇文章值得一读。
You can try gold (
binutils-gold
) instead ofld
.It is supposed to be faster.
Here is a quote from Wikipedia Gold(linker)
The author of gold (Ian Lance Taylor) has published an (longish) article about linkers where he explains his motifs in writing gold and why most linkers are slow. If you are interested in the inner workings of linkers this article is worth reading.
如果您观察到运行
gcc
时速度变慢(而不是直接运行链接器作为ld
),请尝试使用以下命令进行编译。这将打印出所有中间命令,例如内部
collect2
和 Finalld
,并确保传递给这些命令的对象即使在命令完成后也将保留在磁盘上。然后,您应该能够单独运行命令来找到最差的阶段,然后使用不同的选项或分析来运行它。
例如,
如果您需要帮助构建
ld
的调试版本,这里有一个快速入门指南。不过,我建议使用 schroot 或 sbuild 以避免污染您自己的系统。
If you're observing the slowdown running
gcc
(as opposed to directly running the linker asld
), try compiling withThis will print out all the intermediary commands, such as the internal
collect2
and finalld
, as well as ensure that the objects passed to those commands will remain on disk even after the command has completed.Then you should be able to run the commands individually to find the worst stage, and then run it with different options or profiling.
For example,
If you need help building a debug version of
ld
, here's a quick recipe to get you going.Instead of that quick hack, though, I'd recommend using schroot or sbuild to avoid polluting your own system.
回答分析问题; 您应该查看 OProfile - 这是一个系统级分析器,可以分析多个正在运行的进程。 它应该允许您识别链接的哪个子进程花费了最多的时间,此外还将显示哪些功能花费了最多的时间。
To answer the profiling question; you should look at OProfile - this is a system-level profiler that can profile multiple running processes. It should allow you to identify which sub-process of the link is taking the most time, and furthermore will show which functions the most time is being spent.
我想建议两种检查方法:
I'd like to suggest two ways to check: