在callgrind输出中解释_dl_runtime_resolve_xsave'2

Question

在我的程序运行中查看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的调用？我需要担心用这种方法花费的时间吗？

谢谢您的帮助。

Answer 1

_dl_runtime_resolve_xsave在延迟绑定期间在glibc动态加载程序中使用。它在第一次调用函数期间查找函数符号，然后对实现执行尾部调用。除非您在启动程序时在环境中使用类似LD_BIND_NOT=1之类的东西，否则这是一次操作，仅在第一次调用该函数期间发生。延迟绑定会带来一些成本，但是除非您有许多只被一次调用的函数，否则它不会对执行成本造成太大的影响。它更可能是报告工件，可能与尾部调用或XSAVE中使用的异乎寻常的_dl_runtime_resolve_xsave指令有关。

您可以通过使用LD_BIND_NOW=1环境变量设置启动程序来禁用延迟绑定，因为将在启动时解决所有功能，所以将不使用动态加载程序蹦床。另外，您可以与-Wl,-z,now链接以使此更改永久生效（至少对于链接的代码，系统库可能仍对它们自己的功能符号使用延迟绑定）。