linux - dlopen 的优先级高于 linux 上的链接时间

Question

我正在用 gcc 在 linux 上编译一个 C 程序。该程序本身在构建时链接 libc(而不是其他链接)，因此 ldd 给出以下输出:

$ ldd myprogram
    linux-vdso.so.1 =>  (0x00007fffd31fe000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7a991c0000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f7a99bba000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7a98fbb000)

在运行时，这个程序 dlopen() 的库 B 依赖于库 A，当然 dlopen 在返回之前也会加载它。 A 导出一个名为 re_exec 的函数，B 调用该函数(B 链接到 A)。 libc 还导出一个名为 re_exec 的函数。读取输出:

$ readelf -as A.so | grep re_exec
 104: 00000000000044ff   803 FUNC    GLOBAL PROTECTED   11 re_exec
 469: 00000000000044ff   803 FUNC    GLOBAL PROTECTED   11 re_exec

$ readelf -as /lib/x86_64-linux-gnu/libc.so.6 | grep re_exec
 2165: 00000000000e4ae0    39 FUNC    WEAK   DEFAULT   12 re_exec@@GLIBC_2.2.5

问题是当B调用re_exec时，调用的是libc里面的re_exec，而不是A里面的re_exc。

如果在我调用程序时包含 LD_LIBRARY_PRELOAD=/path/to/A.so，那么一切都会按预期工作:Bs 调用 re_exec 正确调用 A，而不是 libc。

dlopen 调用通过 RTLD_NOW | RTLD_GLOBAL。我尝试过使用和不使用 DEEPBIND，并且在任何一种情况下都得到相同的行为。

我还尝试过在 B 之前直接对 A 执行 dlopen()ing，无论是否使用 DEEPBIND，这都不影响行为。

问题:是否有可能以比链接时包含的库(在本例中为 libc)更高的优先级 dlopen A/B？

(请不要建议我将调用重命名为 re_exec 以外的名称；没有用)

Answer 1

嗯，你知道的，我无法重现你的错误。请看一下:

puts.c:

#include <stdio.h>

int puts(const char* _s) {
    return printf("custom puts: %s\n", _s);
}

构建于:

cc -Wall -fPIC -c puts.c -o puts.o
cc -shared -o libputs.so -fPIC -Wl,-soname,libputs.so puts.o

foo.c:

#include <stdio.h>

void foo() {
    puts("Hello, world! I'm foo!");
}

构建于:

cc -Wall -fPIC -c foo.c -o foo.o
cc -L`pwd` -shared -o libfoo.so -fPIC -Wl,-soname,libfoo.so foo.o -lputs

和rundl.c:

#include <dlfcn.h>
#include <assert.h>
#include <stdio.h>

typedef void (*FooFunc)();

int main(void) {
    void *foolib = dlopen("./libfoo.so", RTLD_NOW | RTLD_GLOBAL | RTLD_DEEPBIND);
    assert(foolib != NULL);
    FooFunc foo = (FooFunc)dlsym(foolib, "foo");
    assert(foo != NULL);
    foo();
    return 0;
}

构建于:

cc -c -Wall rundl.c -o rundl.o
cc -o rundl rundl.o -ldl

现在我们可以使用 LD_LIBRARY_PATH=$(pwd) 运行 rundl(这是必需的，因为 libputs.so 不在 ld.so 已知路径，因此 libfoo.so 无法通过 dlopen() & Co 加载:

alex@rhyme ~/tmp/dynlib $ LD_LIBRARY_PATH=`pwd` ./rundl
custom puts: Hello, world! I'm foo!
alex@rhyme ~/tmp/dynlib $ _

如果我们将 libputs.so 移动到 ld.so 已知的目录并(重新)运行 ldconfig 来更新缓存，那么代码将在没有任何特殊环境变量的情况下运行:

alex@rhyme ~/tmp/dynlib $ ldd ./libfoo.so 
    linux-vdso.so.1 (0x00007fff48db8000)
    libputs.so => /usr/local/lib64/libputs.so (0x00007f8595450000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f85950a0000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f8595888000)
alex@rhyme ~/tmp/dynlib $ ./rundl 
custom puts: Hello, world! I'm foo!

如果我链接 libfoo.so w/o -lputs foo() 调用标准的 puts() 来自 libc。就是这样。