在多架构设置中使用 /etc/ld.so.preload

Question

有没有办法使用 ld.so.preload 并覆盖 32 位和 64 位二进制文​​件？

如果我在 ld.so.preload 中列出故障处理程序的 32 位和 64 位版本，那么加载程序总是抱怨其中一个版本无法预加载我运行的任何命令。不完全是惊天动地，因为错误更多的是警告，但我当然可以不用打印输出。

我没有指定绝对路径，而是尝试简单地指定“segv_handler.so”，希望加载程序能够在架构适当的路径中选择库（32 位版本位于 /lib 中，64 位版本位于 /lib64 中）。

显然不太可能。

有没有办法设置 ld.so.preload 以了解架构？或者如果没有，有什么方法可以关闭错误消息吗？

Answer 1

这是可行的：

1. 将 32 位库放在 /path/lib 下，将 64 位库放在 /path/lib64 下
   它们应该具有相同的名称，
2. 并将以下行放入 /etc/ld.so.preload 中：
   /path/$LIB/libname.so

$LIB 将自动获取值“lib”（对于 32 位）或“lib64”（对于 64 位）。

Answer 2

没有理由尝试像这样使用 ld.so.preload 。默认情况下，ld 足够聪明，可以知道如果您运行 64 位应用程序，则仅查找 64 位库，对于 32 位也是如此。

举个例子，如果你有

/lib64/libawesome.so
/lib/libawesome.so

你尝试

gcc -lawesome -o funtime funtime.c

它会选择 gcc 想要构建的默认值， ld 会跳过该构建的不正确位大小的库。

gcc -m64 -lawesome -o funtime funtime.c 将选择 64 位版本

gcc -m32 -lawesome -o funtime funetime.c 将选择 32 位版本。

这假设 /etc/ld.so.conf 默认列出 /lib 和 /lib64 。

Answer 3

可悲的是，我认为答案可能是“不要这样做”。

来自glibc、elf/rtld.c：

通常没有ld.so.preload文件，它应该只用于紧急情况和测试。因此，公开调用等通常会失败。对不存在的文件使用 access() 比使用 open() 更快。所以我们首先这样做。如果成功，我们几乎会做两倍的工作，但这并不重要，因为它不用于生产用途。

Answer 4

您可以使用路径名中的特殊扩展键来提供 32 和 64 位库。
例如，您可以使用 /lib/$PLATFORM/mylib.so 并创建 /lib/i386/mylib.so 和 /lib/x86_64/mylib.so。 Linked 将为您的可执行文件选择正确的一个。