執(zhí)行文件是如何在shell中被"執(zhí)行"的。本文中盡可能少用一些源碼，免得太過于無聊，主要講清這個過程，感興趣的同學可以去查看相應的源碼了解更多的信息。

1.父進程的行為: 復制，等待

執(zhí)行應用程序的方式有很多，從shell中執(zhí)行是一種常見的情況。交互式shell是一個進程(所有的進程都由pid號為1的init進程fork得到，關于這個話題涉及到Linux啟動和初始化，以及idle進程等，有空再說)，當在用戶在shell中敲入./test執(zhí)行程序時，shell先fork()出一個子進程(這也是很多文章中說的子shell),并且wait()這個子進程結束，所以當test執(zhí)行結束后，又回到了shell等待用戶輸入(如果創(chuàng)建的是所謂的后臺進程，shell則不會等待子進程結束，而直接繼續(xù)往下執(zhí)行)。所以shell進程的主要工作是復制一個新的進程，并等待它的結束。

2.子進程的行為: "執(zhí)行"應用程序

2.1 execve()

另一方面,在子進程中會調用execve()加載test并開始執(zhí)行。這是test被執(zhí)行的關鍵，下面我們詳細分析一下。

execve()是操作系統(tǒng)提供的非常重要的一個系統(tǒng)調用，在很多文章中被稱為exec()系統(tǒng)調用(注意和shell內部exec命令不一樣)，其實在Linux中并沒有exec()這個系統(tǒng)調用，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中經過包裝的的庫函數，最后通過系統(tǒng)調用execve()實現(#define __NR_evecve 11，編號11的系統(tǒng)調用)。

exec函數的作用是在當前進程里執(zhí)行可執(zhí)行文件，也就是根據指定的文件名找到可執(zhí)行文件，用它來取代當前進程的內容，并且這個取代是不可逆的，即被替換掉的內容不再保存，當可執(zhí)行文件結束，整個進程也隨之僵死。因為當前進程的代碼段，數據段和堆棧等都已經被新的內容取代，所以exec函數族的函數執(zhí)行成功后不會返回，失敗是返回-1。可執(zhí)行文件既可以是二進制文件，也可以是可執(zhí)行的腳本文件，兩者在加載時略有差別，這里主要分析二進制文件的運行。

2.2 do_execve()

在用戶態(tài)下調用execve()，引發(fā)系統(tǒng)中斷后，在內核態(tài)執(zhí)行的相應函數是do_sys_execve()，而do_sys_execve()會調用do_execve()函數。do_execve()首先會讀入可執(zhí)行文件，如果可執(zhí)行文件不存在，會報錯。然后對可執(zhí)行文件的權限進行檢查。如果文件不是當前用戶是可執(zhí)行的，則execve()會返回-1,報permission denied的錯誤。否則繼續(xù)讀入運行可執(zhí)行文件時所需的信息(見struct linux_binprm)。

2.3 search_binary_handler()

接著系統(tǒng)調用search_binary_handler()，根據可執(zhí)行文件的類型(如shell,a.out,ELF等)，查找到相應的處理函數(系統(tǒng)為每種文件類型創(chuàng)建了一個struct linux_binfmt，并把其串在一個鏈表上，執(zhí)行時遍歷這個鏈表，找到相應類型的結構。如果要自己定義一種可執(zhí)行文件格式，也需要實現這么一個handler)。然后執(zhí)行相應的load_binary()函數開始加載可執(zhí)行文件。

2.4 load_elf_binary()

加載elf類型文件的handler是load_elf_binary()，它先讀入ELF文件的頭部，根據ELF文件的頭部信息讀入各種數據(header information)。再次掃描程序段描述表,找到類型為PT_LOAD的段,將其映射(elf_map())到內存的固定地址上。如果沒有動態(tài)鏈接器的描述段,把返回的入口地址設置成應用程序入口。完成這個功能的是start_thread(),start_thread()并不啟動一個線程，而只是用來修改了pt_regs中保存的PC等寄存器的值，使其指向加載的應用程序的入口。這樣當內核操作結束，返回用戶態(tài)的時候，接下來執(zhí)行的就是應用程序了。

2.5 load_elf_interp()

如果應用程序中使用了動態(tài)鏈接庫，就沒有那么簡單了，內核除了加載指定的可執(zhí)行文件，還要把控制權交給動態(tài)連接器(program interpreter，ld.so in linux)以處理動態(tài)鏈接的程序。內核搜尋段表，找到標記為PT_INTERP的段中所對應的動態(tài)連接器的名稱，并使用load_elf_interp()加載其映像，并把返回的入口地址設置成load_elf_interp()的返回值，即動態(tài)鏈接器入口。當execve退出的時候動態(tài)鏈接器接著運行。動態(tài)連接器檢查應用程序對共享連接庫的依賴性，并在需要時對其進行加載,對程序的外部引用進行重定位。然后動態(tài)連接器把控制權交給應用程序，從ELF文件頭部中定義的程序進入點開始執(zhí)行。(比如test.c中使用了userlib.so中函數foo(),在編譯的時候這個信息被放進了test這個ELF文件中，相應的語句也變成了call fakefoo()。當加載test的時候，知道foo()是一個外部調用,于是求助于動態(tài)鏈接器，加載userlib.so,解析foo()函數地址，然后讓fakefoo()重定向到foo(),這樣call foo()就成功了。)

簡短的說，整個在shell中鍵入./test執(zhí)行應用程序的過程為：當前shell進程fork出一個子進程(子shell)，子進程使用execve來脫離和父進程的關系，加載test文件(ELF格式)到內存中。如果test使用了動態(tài)鏈接庫，就需要加載動態(tài)鏈接器(或者叫程序解釋器)，進一步加載test使用到的動態(tài)鏈接庫到內存，并重定位以供test調用。最后從test的入口地址開始執(zhí)行test。

PS:　現代的動態(tài)鏈接器因為性能等原因都采用了延遲加載和延遲解析技術，延遲加載是動態(tài)連接庫在需要的時候才被加載到內存空間中(通過頁面異常機制)，延遲解析是指到動態(tài)鏈接庫(以加載)中的函數被調用的時候，才會去把這個函數的起始地址解析出來，供調用者使用。動態(tài)鏈接器的實現相當的復雜，為了性能等原因，對堆棧的直接操作被大量使用，感興趣的可以找相關的代碼看看。