程序解释器在可执行文件中的作用是什么？

Question

我正在反汇编 elf 可执行文件并了解 elf 格式。在那里，我看到lib64/ld-linux-x86-64.so.2 在生成的可执行文件中用作程序解释器。

我的猜测是：我在源代码中使用了printf，它必须是动态链接的。当我检查动态部分时，我能够找到对libc.so.6 共享库（标签：DT_NEEDED）的引用。在我的系统中，我在不同的目录中发现了多个具有该名称的文件：

sourav@ubuntu-VirtualBox:/$ sudo find / -name libc.so.6
/usr/lib/x86_64-linux-gnu/libc.so.6
find: ‘/run/user/1000/doc’: Permission denied
find: ‘/run/user/1000/gvfs’: Permission denied
/snap/snapd/13170/lib/x86_64-linux-gnu/libc.so.6
/snap/snapd/11107/lib/x86_64-linux-gnu/libc.so.6
/snap/core18/1988/lib/i386-linux-gnu/libc.so.6
/snap/core18/1988/lib/x86_64-linux-gnu/libc.so.6
/snap/core18/2128/lib/i386-linux-gnu/libc.so.6
/snap/core18/2128/lib/x86_64-linux-gnu/libc.so.6

所以，我猜程序解释器的目的是将这些名称解析为适当的库并在执行期间加载它们。这是正确的吗？

看来，我们也可以有没有程序解释器的可执行文件（程序解释器本身就是这种情况）。在那种情况下，系统/操作系统本身是否会加载共享库？如果是，如何解析库的路径？

是否可以使用 gcc 在没有程序解释器的情况下生成可执行文件？我的 gcc 版本是 'gcc 版本 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)'。

Answer 1

所以，我猜程序解释器的目的是将这些名称解析为适当的库并在执行期间加载它们。这是正确的吗？

是的，但这有点简约。加载动态库包括定位它们，在必要时将它们加载或映射到内存中，并可能延迟地解析内部的动态符号以进行多种重定位。它涉及递归加载库自己需要的库。此外，在动态链接的可执行文件中，程序解释器提供程序入口点（从内核的角度来看），因此它还负责设置和输入程序特定的入口点（例如，C 或 C 中的 main() C++ 程序）。

看来，我们也可以有没有程序解释器的可执行文件（程序解释器本身就是这种情况）。在那种情况下，系统/操作系统本身是否会加载共享库？如果是，如何解析库的路径？

您可以在没有程序解释器的情况下拥有 ELF 可执行文件，但它们不是动态链接的，至少在 ELF 意义上不是。没有要加载的共享库，当然系统也不会加载任何共享库。

是否可以使用 gcc 在没有程序解释器的情况下生成可执行文件？我的 gcc 版本是 'gcc 版本 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)'。

如果您有所有可用库的静态版本，那么您应该能够通过在链接程序时在命令行中包含-static 选项来实现这一点。但是，您完全有可能没有拥有所需的静态库，即使 libc 是您唯一需要的库。