ELFdynamic加载器符号查找顺序

解决dynamic重定位时符号查找的search顺序是什么?

当parsing共享库的符号时,加载器首先在“主要可执行文件”中search(让主要可执行文件覆盖定义…)或者什么?

Solutions Collecting From Web of "ELFdynamic加载器符号查找顺序"

根据我的理解,每个可执行对象都有自己的“查找范围”:

  • 主可执行文件通常是“全局”查找范围中的第一个对象。 这意味着主可执行文件中定义的符号会覆盖依赖共享库中的符号。 使用LD_PRELOAD工具添加的共享对象被添加到全局查找范围,紧跟在主可执行文件之后。
  • 但是,如果正在加载的共享对象使用DF_SYMBOLIC标志,那么在该对象内产生的符号引用将在全局查找范围内搜索之前在对象内查找定义。
  • 使用dlopen()打开的共享对象可能有自己的依赖关系。 如果在调用dlopen()期间未设置RTLD_GLOBAL标志,则将这些依赖项添加到该对象的查找范围,但不影响全局查找范围。 如果将RTLD_GLOBAL标志传递给dlopen() ,则共享对象(及其依赖关系)将被添加到“全局”查找范围中,从而更改后续符号查找的行为。

关于这个主题,建议阅读Ulrich Drepper的“ 如何编写共享库 ”指南。

当解析共享库的符号时,加载器首先在“主要可执行文件”中搜索(让主要可执行文件覆盖定义…)或者什么?

对,就是这样。 动态加载器具有加载的ELF对象的链表(列表的头部是_r_dynamic.r_map ),并线性地搜索该列表中的对象的动态符号表,直到找到正在查找的符号定义。

列表头始终指向主要的可执行文件。 如果给定的符号从主可执行文件中导出,那么它(几乎)总是“胜出”(覆盖其他定义)。

但是,请注意, -Bsymbolic链接器标志改变了一下图片。