_dl_runtime_resolve -- 共享对象何时被加载到内存中？

Question

_dl_runtime_resolve -- 共享对象何时被加载到内存中？

8

我们有一个高性能需求的消息处理系统。最近我们注意到第一条消息所需时间比后续消息长得多。在我们的系统中，通过外部库进行了大量的转换和消息增强。我使用callgrind对这个问题进行了分析，将处理单个消息的“运行”与处理多个消息的“运行”进行了比较（提供了比较基准）。我看到的主要区别是函数“do_lookup_x”的执行时间非常长。查看对此函数的各种调用，它们似乎都由通用函数“_dl_runtime_resolve”调用。我不确定这个函数的作用，但对我来说，这看起来像是各个共享库首次被使用的时候，并且由ld将其加载到内存中。这个假设正确吗？也就是说，二进制文件不会将共享库加载到内存中，直到它们被准备好使用，因此我们会在第一条消息上看到巨大的减速，但在后续消息上不会看到。我们如何避免这种情况？注意：我们的操作在微秒级别。

- Alex

2个回答

4

作为Ignacio Vazquez-Abrams的运行时建议的替代方案，您可以在链接时完成相同的操作。当您链接共享库时，请向链接器传递-z now标志。

- caf

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Ignacio Vazquez-Abrams · Accepted Answer

来自 ld.so(8) 手册的环境变量部分：

   LD_BIND_NOW
          (libc5;  glibc since 2.1.1) If set to a non-empty string, causes
          the dynamic linker to resolve all  symbols  at  program  startup
          instead  of deferring function call resolution to the point when
          they are first referenced.  This is useful when using  a  debug-
          ger.

那么，LD_BIND_NOW=y ./timesensitiveapp。