同名新二进制文件上的dlopen返回旧句柄 [英] dlopen on new binary with same name returns old handle
问题描述
我正在使用dlopen加载动态生成的代码.该程序在代码上调用编译器,并生成一个.so文件,然后由该程序加载以扩展自身.
I'm using dlopen to load dynamically generated code. The program calls the compiler on the code and generates a .so file which is then loaded by the program to extend itself.
问题是,如果我对生成的代码使用相同的名称,则dlopen将返回旧对象的句柄,而不是新对象的句柄.
The problem is that if I use the same name for the generated code, the dlopen returns a handle to the old object, not the new one.
代码如下:
…generate code into test.cpp
system("gcc <args> test.cpp -o test.so");
void *handle = dlopen("test.so");
void *sym = dlsym(handle, "run");
(*sym)();
dlclose(handle);
…Do other work
…generate different code to test.cpp
system("gcc <args> test.cpp -o test.so");
void *handle = dlopen("test.so");
void *sym = dlsym(handle, "run");
(*sym)();
<crash here because the code isn't what was expected>
这是否是 dlopen
的缓存代码中的基本缺陷,还是 dlopen
中没有很好记录的东西?
Is this a basic flaw in dlopen
's cache code or something well known and not well documented in dlopen
?
推荐答案
大多数可能 dlclose
无法卸载该库.这通常发生在它包含 GNU_UNIQUE符号(如果您与静态libstdc ++链接).可以通过
Most probly dlclose
failed to unload the library. This usually happens when it contains GNU_UNIQUE symbols (which tend to sneak in if you link with static libstdc++). This can be verified via
$ readelf -sW --dyn-syms path/to/libxyz.so | grep '\bUNIQUE\b'
...
3808: 0000000000302e78 8 OBJECT UNIQUE DEFAULT 27 _ZNSt8messagesIcE2idE@@GLIBCXX_3.4
要解决此问题,您可以尝试以下操作之一:
To fix this, you can try one of the following:
- 使用
-fvisibility = hidden
和__ attribute __((visibility("default")))
构建库以隐藏唯一的符号 - 使用
-Wl,-version-script
构建以实现相同的目的 - 使用通过
-disable-gnu-unique-object
配置的工具链构建shlib(请参阅
- build library with
-fvisibility=hidden
and__attribute__((visibility("default")))
to hide unique symbols - build with
-Wl,--version-script
to achieve the same - build shlib with toolchain that was configured with
--disable-gnu-unique-object
(see discussion in GCC list)
这篇关于同名新二进制文件上的dlopen返回旧句柄的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!