2

查看我的程序运行时 callgrind 的输出，我看到 125% ！！！的周期花费在 _dl_runtime_resolve_xsave'2（显然是动态链接器的一部分）中，而 100% 花费在 main 中。但它也表示，几乎所有在 _dl_runtime_resolve_xsave'2 中花费的时间实际上都花在了内部方法中（self=0%），但 callgrind 没有显示该方法的任何被调用者。此外，看起来 _dl_runtime_resolve_xsave'2 是从我正在分析的程序中的多个位置调用的。

我可以理解，可能会在 main 之外花费一些时间，因为我正在分析的程序正在使用原型模式，并且在加载动态库时正在构建许多对象原型，但这不能接近 25% 的时间特定的运行（因为如果我在没有输入数据的情况下运行，它所花费的时间比我现在正在分析的运行要少几个数量级）。

此外，该程序在程序启动后未使用 dlopen 打开共享对象。一切都应该在开始时加载。

这是 kcachegrind 窗口的屏幕截图： 在此处输入图像描述

如何解释对 _dl_runtime_resolve_xsave'2 的调用？我需要担心在这种方法中花费的时间吗？

谢谢您的帮助。

4

1 回答 1

6

_dl_runtime_resolve_xsave在惰性绑定期间在 glibc 动态加载器中使用。它在第一次调用函数期间查找函数符号，然后对实现执行尾调用。除非您在启动程序时在环境中使用类似的东西，否则LD_BIND_NOT=1这是一次性操作，仅在第一次调用该函数时发生。惰性绑定有一些成本，但除非您有许多只调用一次的函数，否则它不会对执行成本有太大贡献。它更有可能是一个报告工件，可能与尾部调用XSAVE或_dl_runtime_resolve_xsave.

您可以通过使用环境变量设置启动程序来禁用延迟绑定，LD_BIND_NOW=1不会使用动态加载程序蹦床，因为所有功能都将在启动时解析。或者，您可以链接-Wl,-z,now以使此更改永久化（至少对于您链接的代码，系统库可能仍对其自己的函数符号使用惰性绑定）。

于 2019-02-09T16:57:10.770 回答