我可以让共享库构造函数在重定位之前执行吗？
Can I make shared library constructors execute before relocations?
背景：我正在尝试实现一个系统。简而言之，我有一个链接共享库的应用程序（目前在 Linux 上）。我希望共享库在 运行 时间在多个实现之间切换（例如，基于主机 CPU 是否支持某个指令集）。
在最简单的情况下，我有三个不同的共享库文件：
libtest.so：这是库的 "vanilla" 版本，将用作后备案例。libtest_variant.so：这是库的 "optimized" 变体，如果 CPU 支持它，我想在 运行 时 select。它与 libtest.so.libtest_dispatch.so：这是负责选择在运行时间使用哪个库变体的库。
按照上面链接答案中建议的方法，我正在执行以下操作：
- 最终应用程序链接到
libtest.so。
- 我将
libtest.so 的 DT_SONAME 字段设置为 libtest_dispatch.so。因此，当我 运行 应用程序时，它将加载 libtest_dispatch.so 而不是实际的依赖项 libtest.so.
libtest_dispatch.so 被配置为具有如下所示的构造函数（伪代码）：
__attribute__((constructor)) void init()
{
if (can_use_variant) dlopen("libtest_variant" SHLIB_EXT, RTLD_NOW | RTLD_GLOBAL);
else dlopen("libtest" SHLIB_EXT, RTLD_NOW | RTLD_GLOBAL);
}
对 dlopen() 的调用将加载提供适当实现的共享库，然后应用程序继续。
结果： 这有效！如果我在每个共享库中放置一个同名函数，我可以在 运行 时间验证是否根据调度库使用的条件执行了适当的版本。
问题： 以上适用于我在链接问题中演示的玩具示例。具体来说，如果库只导出函数，它似乎工作正常。但是，一旦有变量在起作用（无论它们是带有 C 链接的全局变量还是像 typeinfo 这样的 C++ 构造），我会在 运行 时间出现未解析的符号错误。
下面的代码演示了这个问题：
libtest.h:
extern int bar;
int foo();
libtest.cc:
#include <iostream>
int bar = 2;
int foo()
{
std::cout << "function call came from libtest" << std::endl;
return 0;
}
libtest_variant.cc:
#include <iostream>
int bar = 1;
int foo()
{
std::cout << "function call came from libtest_variant" << std::endl;
return 0;
}
libtest_dispatch.cc:
#include <dlfcn.h>
#include <iostream>
#include <stdlib.h>
__attribute__((constructor)) void init()
{
if (getenv("USE_VARIANT")) dlopen("libtest_variant" SHLIB_EXT, RTLD_NOW | RTLD_GLOBAL);
else dlopen("libtest" SHLIB_EXT, RTLD_NOW | RTLD_GLOBAL);
}
test.cc:
#include "lib.h"
#include <iostream>
int main()
{
std::cout << "bar: " << bar << std::endl;
foo();
}
我使用以下方法构建库和测试应用程序：
g++ -fPIC -shared -o libtest.so libtest.cc -Wl,-soname,libtest_dispatch.so
g++ -fPIC -shared -o libtest_variant.so libtest_variant
g++ -fPIC -shared -o libtest_dispatch.so libtest_dispatch.cc -ldl
g++ test.cc -o test -L. -ltest -Wl,-rpath,.
然后，我尝试 运行 使用以下命令行进行测试：
> ./test
./test: symbol lookup error: ./test: undefined symbol: bar
> USE_VARIANT=1 ./test
./test: symbol lookup error: ./test: undefined symbol: bar
失败。如果我删除全局变量 bar 的所有实例并尝试仅分派 foo() 函数，那么一切正常。我想弄清楚为什么以及是否可以在存在全局变量的情况下获得我想要的效果。
调试： 在尝试诊断问题时，我在 运行 测试程序时使用了 LD_DEBUG 环境变量。问题似乎归结为：
The dynamic linker performs relocations of global variables from shared libraries very early in the loading process, before constructors from shared libraries are called. Therefore, it tries to locate some global variable symbols before my dispatch library has had a chance to run its constructor and load the library that will actually provide those symbols.
这似乎是一个很大的障碍。有什么方法可以改变这个过程，让我的调度员可以先 运行 吗？
我知道我可以使用 LD_PRELOAD 预加载库。但是，这对我的软件最终 运行 所处的环境来说是一个繁琐的要求。如果可能的话，我想找到一个不同的解决方案。
经过进一步审查，似乎即使我 LD_PRELOAD 图书馆，我也有同样的问题。在全局变量符号解析发生之前，构造函数仍然没有被执行。使用预加载功能只是将所需的库推到库列表的顶部。
它本身可能不是重定位（-fPIC 抑制重定位），而是通过 GOT（全局偏移 Table）进行的惰性绑定，具有相同的效果。这是不可避免的，因为链接器必须在调用 init 之前绑定变量 - 仅仅是因为 init 也可能引用这些符号。
广告解决方案...好吧，一旦解决方案可能是不使用（甚至公开）全局变量到可执行代码。相反，提供一组函数来访问它们。无论如何都不欢迎全局变量:)
Failure. If I remove all instances of the global variable bar and try to dispatch the foo() function only, then it all works.
这在没有全局变量的情况下工作的原因是函数（默认情况下）使用惰性绑定，但变量不能（原因很明显）。
如果您的测试程序与 -Wl,-z,now 链接（这将禁用函数的惰性绑定），则在没有任何全局变量的情况下，您将得到完全相同的失败。
您可以通过将主程序引用的每个全局变量的实例引入调度库来解决此问题。
与您的其他答案所暗示的相反，这不是执行CPU特定调度的标准方法。
有两种标准方法。
旧的：使用 $PLATFORM 作为 DT_RPATH 或 DT_RUNPATH 的一部分。内核会传入一个字符串，例如x86_64，或i386，或i686作为aux向量的一部分，而ld.so将替换$PLATFORM 与那个字符串。
这允许发行版运送 i386 和 i686 优化的库，并有一个程序 select 适当的版本取决于哪个 CPU 它是 运行上。
不用说，这不是很灵活，而且（据我所知）不允许您区分各种 x86_64 变体。
新热点是IFUNC调度，记录在案here。这就是 GLIBC 目前用来提供不同版本的 e.g. memcpy 取决于它 运行 在哪个 CPU 上。还有 target 和 target_clones 属性（记录在同一页上）允许您编译例程的多个变体，针对不同的处理器进行优化（以防您不想在汇编中对它们进行编码).
I'm trying to apply this functionality to an existing, very large library, so just a recompile is the most straightforward way of implementing it.
在那种情况下，您可能必须将二进制文件包装在 shell 脚本中，并根据 CPU 将 LD_LIBRARY_PATH 设置到不同的目录。或者在 运行 程序之前让用户 source 你的脚本。
target_clones does look interesting; is that a recent addition to gcc
我相信 IFUNC 支持大约有 4-5 年历史，GCC 中的自动克隆大约有 2 年历史。所以是的，最近。
背景：我正在尝试实现一个系统
在最简单的情况下，我有三个不同的共享库文件：
libtest.so：这是库的 "vanilla" 版本，将用作后备案例。libtest_variant.so：这是库的 "optimized" 变体，如果 CPU 支持它，我想在 运行 时 select。它与libtest.so. ABI 兼容
libtest_dispatch.so：这是负责选择在运行时间使用哪个库变体的库。
按照上面链接答案中建议的方法，我正在执行以下操作：
- 最终应用程序链接到
libtest.so。 - 我将
libtest.so的DT_SONAME字段设置为libtest_dispatch.so。因此，当我 运行 应用程序时，它将加载libtest_dispatch.so而不是实际的依赖项libtest.so. libtest_dispatch.so被配置为具有如下所示的构造函数（伪代码）：__attribute__((constructor)) void init() { if (can_use_variant) dlopen("libtest_variant" SHLIB_EXT, RTLD_NOW | RTLD_GLOBAL); else dlopen("libtest" SHLIB_EXT, RTLD_NOW | RTLD_GLOBAL); }对
dlopen()的调用将加载提供适当实现的共享库，然后应用程序继续。
结果： 这有效！如果我在每个共享库中放置一个同名函数，我可以在 运行 时间验证是否根据调度库使用的条件执行了适当的版本。
问题： 以上适用于我在链接问题中演示的玩具示例。具体来说，如果库只导出函数，它似乎工作正常。但是，一旦有变量在起作用（无论它们是带有 C 链接的全局变量还是像 typeinfo 这样的 C++ 构造），我会在 运行 时间出现未解析的符号错误。
下面的代码演示了这个问题：
libtest.h:
extern int bar;
int foo();
libtest.cc:
#include <iostream>
int bar = 2;
int foo()
{
std::cout << "function call came from libtest" << std::endl;
return 0;
}
libtest_variant.cc:
#include <iostream>
int bar = 1;
int foo()
{
std::cout << "function call came from libtest_variant" << std::endl;
return 0;
}
libtest_dispatch.cc:
#include <dlfcn.h>
#include <iostream>
#include <stdlib.h>
__attribute__((constructor)) void init()
{
if (getenv("USE_VARIANT")) dlopen("libtest_variant" SHLIB_EXT, RTLD_NOW | RTLD_GLOBAL);
else dlopen("libtest" SHLIB_EXT, RTLD_NOW | RTLD_GLOBAL);
}
test.cc:
#include "lib.h"
#include <iostream>
int main()
{
std::cout << "bar: " << bar << std::endl;
foo();
}
我使用以下方法构建库和测试应用程序：
g++ -fPIC -shared -o libtest.so libtest.cc -Wl,-soname,libtest_dispatch.so
g++ -fPIC -shared -o libtest_variant.so libtest_variant
g++ -fPIC -shared -o libtest_dispatch.so libtest_dispatch.cc -ldl
g++ test.cc -o test -L. -ltest -Wl,-rpath,.
然后，我尝试 运行 使用以下命令行进行测试：
> ./test
./test: symbol lookup error: ./test: undefined symbol: bar
> USE_VARIANT=1 ./test
./test: symbol lookup error: ./test: undefined symbol: bar
失败。如果我删除全局变量 bar 的所有实例并尝试仅分派 foo() 函数，那么一切正常。我想弄清楚为什么以及是否可以在存在全局变量的情况下获得我想要的效果。
调试： 在尝试诊断问题时，我在 运行 测试程序时使用了 LD_DEBUG 环境变量。问题似乎归结为：
The dynamic linker performs relocations of global variables from shared libraries very early in the loading process, before constructors from shared libraries are called. Therefore, it tries to locate some global variable symbols before my dispatch library has had a chance to run its constructor and load the library that will actually provide those symbols.
这似乎是一个很大的障碍。有什么方法可以改变这个过程，让我的调度员可以先 运行 吗？
我知道我可以使用 LD_PRELOAD 预加载库。但是，这对我的软件最终 运行 所处的环境来说是一个繁琐的要求。如果可能的话，我想找到一个不同的解决方案。
经过进一步审查，似乎即使我 LD_PRELOAD 图书馆，我也有同样的问题。在全局变量符号解析发生之前，构造函数仍然没有被执行。使用预加载功能只是将所需的库推到库列表的顶部。
它本身可能不是重定位（-fPIC 抑制重定位），而是通过 GOT（全局偏移 Table）进行的惰性绑定，具有相同的效果。这是不可避免的，因为链接器必须在调用 init 之前绑定变量 - 仅仅是因为 init 也可能引用这些符号。
广告解决方案...好吧，一旦解决方案可能是不使用（甚至公开）全局变量到可执行代码。相反，提供一组函数来访问它们。无论如何都不欢迎全局变量:)
Failure. If I remove all instances of the global variable bar and try to dispatch the foo() function only, then it all works.
这在没有全局变量的情况下工作的原因是函数（默认情况下）使用惰性绑定，但变量不能（原因很明显）。
如果您的测试程序与 -Wl,-z,now 链接（这将禁用函数的惰性绑定），则在没有任何全局变量的情况下，您将得到完全相同的失败。
您可以通过将主程序引用的每个全局变量的实例引入调度库来解决此问题。
与您的其他答案所暗示的相反，这不是执行CPU特定调度的标准方法。
有两种标准方法。
旧的：使用 $PLATFORM 作为 DT_RPATH 或 DT_RUNPATH 的一部分。内核会传入一个字符串，例如x86_64，或i386，或i686作为aux向量的一部分，而ld.so将替换$PLATFORM 与那个字符串。
这允许发行版运送 i386 和 i686 优化的库，并有一个程序 select 适当的版本取决于哪个 CPU 它是 运行上。
不用说，这不是很灵活，而且（据我所知）不允许您区分各种 x86_64 变体。
新热点是IFUNC调度，记录在案here。这就是 GLIBC 目前用来提供不同版本的 e.g. memcpy 取决于它 运行 在哪个 CPU 上。还有 target 和 target_clones 属性（记录在同一页上）允许您编译例程的多个变体，针对不同的处理器进行优化（以防您不想在汇编中对它们进行编码).
I'm trying to apply this functionality to an existing, very large library, so just a recompile is the most straightforward way of implementing it.
在那种情况下，您可能必须将二进制文件包装在 shell 脚本中，并根据 CPU 将 LD_LIBRARY_PATH 设置到不同的目录。或者在 运行 程序之前让用户 source 你的脚本。
target_clones does look interesting; is that a recent addition to gcc
我相信 IFUNC 支持大约有 4-5 年历史，GCC 中的自动克隆大约有 2 年历史。所以是的，最近。