Linux启动ELF可执行文件的过程
2013-08-05 13:17
344 查看
总结一下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);[/c] 系统支持的每一种文件格式,都会有一个linux_binfmt结构的注册项。内核找到相应的注册项,并调用load_binary回调函数。对于ELF文件来说,load_elf_binary()就会被查找到并调用。
if (retval < 0)
goto out;
[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所指向的代码,于是在下一指令周期,一个全新的进程就启动了。本文出自 “第二月的博客” 博客,请务必保留此出处http://2ndmoon.blog.51cto.com/6542214/1283727
相关文章推荐
- Linux启动ELF可执行文件的过程
- Linux启动过程中几个重要配置文件的执行过程
- linux下系统启动时,几个配置文件 /etc/profile、~/.bash_profile 等几个文件的执行过程,先后顺序
- Linux启动过程中几个重要配置文件的执行过程
- Linux启动过程中几个重要配置文件的执行过程
- Linux启动过程中几个重要配置文件的执行过程_newcch-ChinaUnix博客
- linux下系统启动时,几个配置文件 /etc/profile、~/.bash_profile 等几个文件的执行过程,先后顺序
- 在登录Linux时要执行文件的过程(可设置开机启动)
- Linux启动过程中几个重要配置文件的执行过程
- linux下系统启动时,几个配置文件 /etc/profile、~/.bash_profile 等几个文件的执行过程,先后顺序
- Linux启动过程中几个重要配置文件的执行过程_阿4is痞男-ChinaUnix博客
- Linux启动过程中几个重要配置文件的执行过程
- Linux启动时~/.bash_profile等文件的执行过程
- 如何在Linux ELF格式的文件(可执行binary,以及so文件)中定位到对应的函数位置
- Linux下ELF的执行过程
- 登录Linux时要执行文件的过程
- Linux下从原文件到可执行文件的过程
- linux汇编之——(1)ELF:Linux可执行程序文件格式
- linux可执行文件的加载过程
- 好文转载:ELF文件格式及程序加载执行过程总汇