1.父进程的行为: 复制，等待
执行应用程序的方式有很多，从shell中执行是一种常见的情况。交互式shell是一个进程(所有的进程都由pid号为1的init进程fork得到，关于这个话题涉及到Linux启动和初始化，以及idle进程等，有空再说)，当在用户在shell中敲入./test执行程序时，shell先fork()出一个子进程(这也是很多文章中说的子shell),并且wait()这个子进程结束，所以当test执行结束后，又回到了shell等待用户输入(如果创建的是所谓的后台进程，shell则不会等待子进程结束，而直接继续往下执行)。所以shell进程的主要工作是复制一个新的进程，并等待它的结束。
2.子进程的行为: "执行"应用程序
2.1 execve()
另一方面,在子进程中会调用execve()加载test并开始执行。这是test被执行的关键，下面我们详细分析一下。
execve()是操作系统提供的非常重要的一个系统调用，在很多文章中被称为exec()系统调用(注意和shell内部exec命令不一样)，其实在Linux中并没有exec()这个系统调用，exec只是用来描述一组函数，它们都以exec开头，分别是：
#include
int execl(const char *path, const char *arg, ...);
int execlp(const char *file, const char *arg, ...);
int execle(const char *path, const char *arg, ..., char *const envp[]);
int execv(const char *path, char *const argv[]);
int execvp(const char *file, char *const argv[]);
int execve(const char *path, char *const argv[], char *const envp[]);
这几个都是都是libc中经过包装的的库函数，最后通过系统调用execve()实现(#define __NR_evecve 11，编号11的系统调用)。
exec 函数的作用是在当前进程里执行可执行文件，也就是根据指定的文件名找到可执行文件，用它来取代当前进程的内容，并且这个取代是不可逆的，即被替换掉的内容不再保存，当可执行文件结束，整个进程也随之僵死。因为当前进程的代码段，数据段和堆栈等都已经被新的内容取代，所以exec函数族的函数执行成功后不会返回，失败是返回-1。可执行文件既可以是二进制文件，也可以是可执行的脚本文件，两者在加载时略有差别，这里主要分析二进制文件的运行。
2.2 do_execve()
在用户态下调用execve()，引发系统中断后，在内核态执行的相应函数是do_sys_execve()，而do_sys_execve()会调用 do_execve()函数。do_execve()首先会读入可执行文件，如果可执行文件不存在，会报错。然后对可执行文件的权限进行检查。如果文件不是当前用户是可执行的，则execve()会返回-1,报permission denied的错误。否则继续读入运行可执行文件时所需的信息(见struct linux_binprm)。
2.3 search_binary_handler()
接着系统调用search_binary_handler()，根据可执行文件的类型(如shell,a.out,ELF等)，查找到相应的处理函数(系统为每种文件类型创建了一个struct linux_binfmt，并把其串在一个链表上，执行时遍历这个链表，找到相应类型的结构。如果要自己定义一种可执行文件格式，也需要实现这么一个 handler)。然后执行相应的load_binary()函数开始加载可执行文件。
2.4 load_elf_binary()
加载elf类型文件的handler是load_elf_binary()，它先读入ELF文件的头部，根据ELF文件的头部信息读入各种数据 (header information)。再次扫描程序段描述表,找到类型为PT_LOAD的段,将其映射(elf_map())到内存的固定地址上。如果没有动态链接器的描述段,把返回的入口地址设置成应用程序入口。完成这个功能的是start_thread(),start_thread()并不启动一个线程，而只是用来修改了pt_regs中保存的PC等寄存器的值，使其指向加载的应用程序的入口。这样当内核操作结束，返回用户态的时候，接下来执行的就是应用程序了。
ps：elf文件是一种灵活的二进制文件，可以是包含了数据和文件的可执行的程序，可以是可重定位文件，这些数据是和其他重定位文件和共享的object文件一起链接起来使用的。# file libfoo.o libfoo.o: ELF 32-bit LSB relocatable, Intel 80386, version 1, not stripped 。也或者是一种共享库文件，这些数据是在连接时候被连接器ld和运行时动态连接器使用的，例如 ld-linux.so.1
2.5 load_elf_interp()
如果应用程序中使用了动态链接库，就没有那么简单了，内核除了加载指定的可执行文件，还要把控制权交给动态连接器(program interpreter，ld.so in linux)以处理动态链接的程序。内核搜寻段表，找到标记为PT_INTERP的段中所对应的动态连接器的名称，并使用 load_elf_interp()加载其映像，并把返回的入口地址设置成load_elf_interp()的返回值，即动态链接器入口。当 execve退出的时候动态链接器接着运行。动态连接器检查应用程序对共享连接库的依赖性，并在需要时对其进行加载,对程序的外部引用进行重定位。然后动态连接器把控制权交给应用程序，从ELF文件头部中定义的程序进入点开始执行。(比如test.c中使用了userlib.so中函数foo(),在编译的时候这个信息被放进了test这个ELF文件中，相应的语句也变成了call fakefoo()。当加载test的时候，知道foo()是一个外部调用,于是求助于动态链接器，加载userlib.so,解析foo()函数地址，然后让fakefoo()重定向到foo(),这样call foo()就成功了。)
简短的说，整个在shell中键入./test执行应用程序的过程为：当前shell进程fork出一个子进程(子shell)，子进程使用execve来脱离和父进程的关系，加载test文件(ELF格式)到内存中。如果test使用了动态链接库，就需要加载动态链接器(或者叫程序解释器)，进一步加载 test使用到的动态链接库到内存，并重定位以供test调用。最后从test的入口地址开始执行test。
PS: 现代的动态链接器因为性能等原因都采用了延迟加载和延迟解析技术，延迟加载是动态连接库在需要的时候才被加载到内存空间中(通过页面异常机制)，延迟解析是指到动态链接库(以加载)中的函数被调用的时候，才会去把这个函数的起始地址解析出来，供调用者使用。动态链接器的实现相当的复杂，为了性能等原因，对堆栈的直接操作被大量使用，感兴趣的可以找相关的代码看看。
