Question

背景：我正在尝试实施系统like that described in this previous answer。简而言之，我有一个链接到共享库的应用程序（目前在Linux上）。我希望该共享库在运行时在多个实现之间切换（例如，基于主机CPU是否支持某个指令集）。

在最简单的情况下，我有三个不同的共享库文件：

libtest.so：这是该库的“vanilla”版本，将用作后备案例。
libtest_variant.so：这是库的“优化”变体，如果CPU支持它，我想在运行时选择它。它与libtest.so ABI兼容。
libtest_dispatch.so：这是负责选择在运行时使用哪个库变体的库。

根据上面链接答案中建议的方法，我正在做以下事情：

最终申请与libtest.so。
我将DT_SONAME libtest.so字段设置为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环境变量进行了一些操作。似乎问题归结为：

动态链接器在加载过程的早期，在调用共享库的构造函数之前，从共享库执行全局变量的重定位。因此，它尝试在我的调度库有机会运行其构造函数并加载实际提供这些符号的库之前找到一些全局变量符号。

这似乎是一个很大的障碍。有什么方法可以改变这个过程，以便我的调度员可以先运行？

~~我知道我可以使用LD_PRELOAD预加载库。但是，这对我的软件最终会运行的环境来说是一个繁琐的要求。如果可能的话，我想找到一个不同的解决方案。~~

经过进一步审核，即使我LD_PRELOAD图书馆，我也有同样的问题。在发生全局变量符号解析之前，构造函数仍未执行。使用预加载功能只需将所需的库推送到库列表的顶部。

Answer 1

失败。如果我删除全局变量栏的所有实例并尝试仅调度foo（）函数，那么一切正常。

没有全局变量的原因是函数（默认情况下）使用延迟绑定，但变量不能（出于显而易见的原因）。

如果您的测试程序与-Wl,-z,now链接（这将禁用函数的延迟绑定），您将获得完全相同的失败而没有任何全局变量。

您可以通过将主程序引用的每个全局变量的实例引入到调度库中来解决此问题。

与您的其他答案所暗示的相反，这是不是执行特定于CPU的调度的标准方法。

有两种标准方式。

旧版：使用$PLATFORM作为DT_RPATH或DT_RUNPATH的一部分。内核将传递一个字符串，例如x86_64，i386或i686作为aux向量的一部分，ld.so将替换{$PLATFORM 1}}用那个字符串。

这允许发行版同时发送i386和i686优化的库，并根据运行的CPU选择合适的版本。

毋庸置疑，这不是非常灵活，而且（据我所知）并不能让您区分各种x86_64变体。

新的热度为IFUNC发送，记录here。这就是GLIBC目前用来提供不同版本的产品。 memcpy取决于它运行的CPU。还有target和target_clones属性（在同一页面上记录），允许您编译例程的多个变体，针对不同的处理器进行了优化（如果您不想编码它们）在集会中。）

我试图将此功能应用于现有的非常大的库，因此重新编译是实现它的最直接的方法。

在这种情况下，您可能必须将二进制文件包装在shell脚本中，并根据CPU将LD_LIBRARY_PATH设置为不同的目录。或者在运行程序之前让用户source编写脚本。

target_clones确实看起来很有趣;是最近添加到gcc

我认为IFUNC支持约为4-5岁，GCC中的自动克隆约为2年。所以，是的，最近。

Answer 2

它本身可能不是重定位（-fPIC suppressess relocations），而是通过GOT（全局偏移表）的延迟绑定，具有相同的效果。这是不可避免的，因为链接器必须在调用init之前绑定变量 - 只是因为init也可以引用这些符号。

Ad for solutions ...好吧，一旦解决方案可能不使用（或甚至公开）全局变量到可执行代码。相反，提供一组函数来访问它们。不管怎样，全球变量都不受欢迎：）

我可以在重定位之前执行共享库构造函数吗？

2 个答案: