真正的入口点是动态加载器中的 Linux 程序以及如何在调用堆栈中显示它？

我认为使用共享库（未使用 -static 编译）的 Linux 程序的启动过程是：

(1) 在bash中输入可执行文件的名称

(2) Bash 读取可执行文件，发现它包含一个“.interp”部分，其中包含动态加载器的名称。

(3) Bash fork 一个新进程，在子进程中执行动态加载器，并将可执行文件的名称/路径作为参数传递给动态加载器。但我不确定入口点是什么，动态加载器中没有“_start”，即 /lib64/ld-linux-x86-64.so.2

(4) exec从Linux内核返回用户态后，用户态执行的第一条指令应该是动态加载器的入口点。

(5) 动态加载器加载可执行文件（其名称/路径作为参数传入）及其所有依赖项，动态加载器将调用每个加载模块的“.init_array”部分中的方法。特别是，主可执行文件中“.init_array”部分中的方法也应该由动态加载器执行。从动态加载器的角度来看，主可执行文件和共享库之间确实没有太大区别。

(6) 动态加载器调用主可执行文件的入口点，即_start。这意味着，如果动态加载器的入口点也被称为 _start，那么从这一点开始，调用堆栈中应该有两个 _start。

以上理解有问题吗？

但问题是，当通过gdb调试程序并使用

set backtrace past-main
start
bt

它只显示到 _start 的回溯，但是动态加载器中的调用堆栈呢？也试过了：

set backtrace past-entry
start
bt

现在它在 main 之前什么都不显示...

以上理解有问题吗？

是的：大部分是错误的。

bash 看起来并不在二进制文件的“内部”，它只是 fork() 和 exec()。 kernel 映射二进制文件，发现其中有一个 PT_INTERP segment（在运行时不关心 sections），映射解释器并将控制权传递给它。

从Linux内核exec返回到用户态后，用户态执行的第一条指令应该是动态加载器的入口点。

正确。

动态加载器加载可执行文件

这又是部分错误：内核已经映射了主可执行文件。

动态加载器调用主可执行文件的入口点，即_start。这意味着，如果动态加载器的入口点也被称为 _start，那么从这一点开始，调用堆栈中应该有两个 _start。

动态加载器将控制权转移到主要的可执行入口点。控制转移不一定是 CALL，它可以是 JMP，在这种情况下，您不应该期望找到 a.out:_entry 的任何调用者。

在 x86_64 上，这发生在 _dl_start_user 汇编例程中（在 sysdeps/x86_64/dl-machine.h 文件中），如下所示：

_dl_start_user:
    # Save the user entry point address in %r12.
    movq %rax,%r12
...
    # Jump to the user's entry point.
    jmp *%r12