ELF 共享库可移植性答案

【问题标题】：ELF shared library portabilityELF 共享库可移植性
【发布时间】：2016-11-17 15:05:28
【问题描述】：

想象一下，我有一个 ELF 格式的共享库，它只导出一个具有确定调用约定的确定符号（入口点），并且根本不导入任何符号。

我能否在不同的 UNIX 风格（Linux、FreeBSD、Solaris）之间 dlopen/dlsym/dlclose 这个共享库？

【问题讨论】：

【解决方案1】：

我能否在不同的 UNIX 风格（Linux、FreeBSD、Solaris）之间 dlopen/dlsym/dlclose 这个共享库？

假设您的库是完全独立的，不调用任何外部例程，也不发出任何系统调用……答案仍然是否定的。

在 ELF 标头 e_ident[EI_OSABI] 字节中，您将拥有 ELFOSABI_GNU、ELFOSABI_FREEBSD 或 ELFOSABI_SOLARIS 之一。加载程序将（或至少应该）拒绝为“错误”操作系统构建的库 dlopen 的尝试。

但是，如果您修补该字节以匹配当前操作系统，那么dlopen 可能会起作用。

【讨论】：

【解决方案2】：

不，ELF 加载器和 ELF 文件的约定因操作系统以及用于与内核交互的系统调用而异。

您可以编辑文件以更改加载器，以便 FreeBSD 或 Solaris 加载器接受它，如果您只使用最小的子集，它可能加载，但它是除非它只是一堆纯函数，否则您不太可能从中获得很多东西。

【讨论】：

共享库中没有任何外部符号或系统调用。只有用户空间代码。
“用户空间代码”……不仅仅是模糊的。调用系统调用是用户空间代码。如果它只是数据处理函数（如我所说，纯函数），它可能会与足够的按摩一起工作。但是，如果任何事情都依赖于任何类型的共享状态，那么它根本不可能工作。除了可能在 FreeBSD 上，因为它有（有？）加载 Linux ELF 文件的能力。
关于 sysenter/trap/ring2/非特权代码中可用的任何指令，您是绝对正确的。更清楚地说——我的意思是共享库中的代码是完全独立的——外部没有调用。