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

Question

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

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

• libtest.so：这是库的“香草”版本，将用作后备案例。
• libtest_variant.so：这是库的“优化”变体，如果 CPU 支持，我想在运行时选择它。它与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 环境变量。看来问题归结为：

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

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

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

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

Answer 1

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

这在没有全局变量的情况下工作的原因是函数（默认情况下）使用惰性绑定，但变量不能（原因很明显）。

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

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

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

有两种标准方式。

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

这允许发行版同时发布 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 抑制重定位），而是通过 GOT（全局偏移表）进行的惰性绑定，具有相同的效果。这是不可避免的，因为链接器必须在调用 init 之前绑定变量 - 仅仅是因为 init 也可能引用这些符号。

解决方案广告...好吧，一旦解决方案可能是不使用（甚至公开）全局变量给可执行代码。相反，提供一组函数来访问它们。无论如何都不欢迎全局变量:)