问题描述
我认为使用共享库(未使用 -static 编译)的 Linux 程序的启动过程是:
(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