Linux启动ELF可执行文件的过程

2019-07-13 07:33发布

总结一下Linux内核启动一个ELF可执行文件的大概过程,其中大部分的细节都并没有深究过,但总的流程还算比较清楚。如果涉及到与体系结构有关的内容,只讲ARM的。 就从do_execve()函数开始讲起,因为无论是系统调用(即一个进程启动另一个进程)还是启动kernel线程(即系统自己决定启动一个进程,比如系统引导后由kernel启动的第一个进程init)都会调到这个函数。 do_execve()只是一个封装,接着就直接调用do_execve_common(),这是真正主要的部分。下面只捡主要的步骤说,细节不论。 先是构造一个结构体struct linux_binprm的实例,这个结构里将包含有可执行文件的各种参数。 接下来,调用bprm_mm_init()初始化进程的虚拟内存,其中比较重要的,一个是构造了进程的mm_struct结构,再就是为进程申请了页表。当然这个时候还没有什么内容被映射到进程空间,所以只需要申请PGD就可以了。 [c]
retval = bprm_mm_init(bprm);
if (retval)
goto out_file;
[/c] 不过也有例外,在函数pgd_t *pgd_alloc(struct mm_struct *mm)中(arch/arm/mm/pgd.c),还会区分“中断向量表”是在低内存还是在高内存。在比较早的ARM系统中,中断向量表只能被存放在靠近内存0地址附近(一页就够了),所以所有的进程都必须注意这一点,并且把这一页给让出来;但是在ARMv4之后,中断向量表的位置就可以配置,可以把中断向量表的位置设置到高内存处(靠近4G边界的地方),这样的话,中断向量表就位于内核空间,在0~3G的进程空间中就不用再特别考虑它了。 下面的这段代码就是做了一个判断,如果中断向量表在低地址处,就在这里先把从0地址开始的这一页给映射起来,并把它给占上。 [c]
pgd_t *pgd_alloc(struct mm_struct *mm)
{
......
if (!vectors_high()) {
new_pud = pud_alloc(mm, new_pgd, 0);
if (!new_pud)
goto no_pud;

new_pmd = pmd_alloc(mm, new_pud, 0);
if (!new_pmd)
goto no_pmd;
......
}
[/c] 接着,调用prepare_binprm(),它会拷贝可执行文件最开始处的128个字节,用于识别文件格式。 [c]
retval = prepare_binprm(bprm);
if (retval < 0)
goto out;
[/c] 下面会做三次从当前进程空间到内核空间的字符串复制,这些信息分别是文件名、环境变量和参数。因为这些字符信息现在还在当前的用户进程空间中,现在先把它们复制到bprm中去,等到新的进程空间准备好了,再把它们复制到新进程中去(这是在load_elf_binary()->create_elf_table()中完成的)。 [c]
retval = copy_strings_kernel(1, &bprm->filename, bprm);
if (retval < 0)
goto out;

bprm->exec = bprm->p;
retval = copy_strings(bprm->envc, envp, bprm);
if (retval < 0)
goto out;

retval = copy_strings(bprm->argc, argv, bprm);
if (retval < 0)
goto out;
[/c] 在这之后就调用search_binary_handler(),在其中根据前面读到的文件头信息来识别可执行文件格式。 [c]
retval = search_binary_handler(bprm,regs);
if (retval < 0)
goto out;
[/c] 系统支持的每一种文件格式,都会有一个linux_binfmt结构的注册项。内核找到相应的注册项,并调用load_binary回调函数。对于ELF文件来说,load_elf_binary()就会被查找到并调用。 [c]
struct linux_binfmt {
struct list_head lh;
struct module *module;
int (*load_binary)(struct linux_binprm *, struct pt_regs * regs);
int (*load_shlib)(struct file *);
int (*core_dump)(struct coredump_params *cprm);
unsigned long min_coredump;
};
[/c] load_elf_binary()的工作已经在前一篇中提到过,它解析了ELF文件,并映射了各区域的VMA,构造了进程的虚拟内存空间。在这个函数的最后,调用了一个与体系结构相关的宏:(arch/arm/include/asm/processor.h) [c]
#define start_thread(regs,pc,sp)
({
unsigned long *stack = (unsigned long *)sp;
set_fs(USER_DS);
memset(regs->uregs, 0, sizeof(regs->uregs));
if (current->personality & ADDR_LIMIT_32BIT)
regs->ARM_cpsr = USR_MODE;
else
regs->ARM_cpsr = USR26_MODE;
if (elf_hwcap & HWCAP_THUMB && pc & 1)
regs->ARM_cpsr |= PSR_T_BIT;
regs->ARM_cpsr |= PSR_ENDSTATE;
regs->ARM_pc = pc & ~1;
regs->ARM_sp = sp;
regs->ARM_r2 = stack[2];
regs->ARM_r1 = stack[1];
regs->ARM_r0 = stack[0];
nommu_start_thread(regs);
})
[/c] 它的作用很重要,是设置寄存器,可以看到,这里已经把十分关键的cpsr、pc以及sp都设置好,进程基本上已经就绪了,随时可以投入CPU运行。那么准备好的进程究竟什么时候被装入CPU呢?只需要跟踪参数regs就能够找到答案。 struct pt_regs结构的参数regs是从do_execve()开始就一直带下来的,在此之前它又从哪来呢?再往上一级,看看系统调用sys_execve(),在这里regs仍然是传入的参数。我还不太清楚系统调用的发生过程,但是可以猜测,这个regs应该是中断发生时用户进程的寄存器信息。 现在,当新的进程已经准备就绪,再回到sys_execve()中时,regs里面已经是新进程的寄存器信息了,如果再往上,中断将结束返回,CPU重新回到用户模式,而这时寄存器中正是新进程的数据,pc正指向ELF文件中elf_entry所指向的代码,于是在下一指令周期,一个全新的进程就启动了。