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

总结一下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就能够找到答案。

structpt_regs结构的参数regs是从do_execve()开始就一直带下来的，在此之前它又从哪来呢？再往上一级，看看系统调用sys_execve()，在这里regs仍然是传入的参数。我还不太清楚系统调用的发生过程，但是可以猜测，这个regs应该是中断发生时用户进程的寄存器信息。

现在，当新的进程已经准备就绪，再回到sys_execve()中时，regs里面已经是新进程的寄存器信息了，如果再往上，中断将结束返回，CPU重新回到用户模式，而这时寄存器中正是新进程的数据，pc正指向ELF文件中elf_entry所指向的代码，于是在下一指令周期，一个全新的进程就启动了。