根据我收集到的信息，共享库默认可见符号的符号名称查找以呼吸优先顺序遍历共享库依赖树，可执行程序是该搜索树的根。由一个 DT_NEEDED 列表链接的所有库都处于此树的同一级别。
因此，当查找符号“foo”时，在我看来，它的查找确定性地总是在运行时绑定(bind)到相同的库或可执行文件。动态链接器是否利用了这一点并具有某种“全局符号表”(可能与链接映射列表相关联)，一旦第一次查找符号就知道哪个符号属于哪个共享库，并获取该符号的地址当另一个共享库第二次查找该符号时，该库的 GOT 中的符号？或者符号是否总是被查找，就好像这是它的第一次查找一样？
最佳答案
Thus, when a symbol "foo" is looked up, it seems to me that its lookup is deterministically always bound to the same library or executable at runtime.
这种观点方式过于简单化了。有很多并发症，例如在引用 DSO 上存在 DT_SYMBOLIC，在加载定义 DSO 时存在 RTLD_LOCAL(如果它没有直接链接)，我确信我现在不记得的其他一些并发症。
Does the dynamic linker exploit this and has a "global symbol table" of sorts
GLIBC 加载器不会那样做。
Or will the symbol always be looked up as if this was its first lookup?
是的。您可以使用 LD_DEBUG=symbols,bindings ./a.out
关于linux - 是否总是再次从符号 namespace 的根开始查找不同共享库中的相同符号？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/39406735/