查看我的程序运行的 callgrind 输出，我看到 125% !!!的周期花费在 _dl_runtime_resolve_xsave'2(显然是动态链接器的一部分)，而 100% 花费在 main 中。但它也表示几乎所有在 _dl_runtime_resolve_xsave'2 内花费的时间实际上都花在了内部方法中(self=0%)，但 callgrind 没有显示此方法的任何被调用者。 此外，看起来 _dl_runtime_resolve_xsave'2 是从我正在分析的程序中的几个地方调用的。
我可以理解，有些时间可以花在 main 之外，因为我正在分析的程序正在使用原型(prototype)模式，并且在加载动态库时正在构建许多对象原型(prototype)，但这不能达到接近 25% 的时间该特定运行的时间(因为如果我在没有输入数据的情况下运行，它所花费的时间比我现在正在分析的运行少几个数量级)。
此外，该程序在启动后未使用 dlopen 打开共享对象。一切都应该在开始时加载。
这是 kcachegrind 窗口的屏幕截图:
如何解释对 _dl_runtime_resolve_xsave'2 的调用？我需要担心用这种方法花费的时间吗？
感谢您的帮助。
最佳答案
_dl_runtime_resolve_xsave 在惰性绑定(bind)期间用于 glibc 动态加载器。它在函数的第一次调用期间查找函数符号，然后对实现执行尾调用。除非您在启动程序时在环境中使用类似 LD_BIND_NOT=1 的东西，否则这是一次性操作，仅在第一次调用该函数时发生。惰性绑定(bind)有一些成本，但除非您有许多只调用一次的函数，否则它不会对执行成本产生太大影响。它更可能是报告工件，可能与尾部调用或 _dl_runtime_resolve_xsave 中使用的相当奇特的 XSAVE 指令有关。
您可以通过使用 LD_BIND_NOW=1 环境变量设置启动程序来禁用延迟绑定(bind)，将不会使用动态加载程序蹦床，因为所有功能都将在启动时解析。或者，您可以使用 -Wl,-z,now 进行链接以使此更改永久生效(至少对于您链接的代码，系统库可能仍对其自己的函数符号使用惰性绑定(bind))。
关于c++ - 在 callgrind 输出中解释 _dl_runtime_resolve_xsave'2，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/54597742/