Linux應用程序加載機制-你真的清楚嗎？
前戲
我們都知道，Linux應用程序（可執(zhí)行文件）可以在shell中啟動，那可執(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（）是什么呢？
execve()是操作系統(tǒng)提供的非常重要的一個系統(tǒng)調用，在很多文章中被稱為exec()系統(tǒng)調用(注意和shell內部exec命令不一樣)，其實在Linux中并沒有exec()這個系統(tǒng)調用，exec只是用來描述一組函數(shù)，它們都以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中經(jīng)過包裝的的庫函數(shù)，***通過系統(tǒng)調用execve()實現(xiàn)(#define __NR_evecve 11，編號11的系統(tǒng)調用)。
exec函數(shù)的作用是在當前進程里執(zhí)行可執(zhí)行文件，也就是根據(jù)指定的文件名找到可執(zhí)行文件，用它來取代當前進程的內容，并且這個取代是不可逆的，即被替換掉的內容不再保存，當可執(zhí)行文件結束，整個進程也隨之僵死。因為當前進程的代碼段，數(shù)據(jù)段和堆棧等都已經(jīng)被新的內容取代，所以exec函數(shù)族的函數(shù)執(zhí)行成功后不會返回，失敗是返回-1?？蓤?zhí)行文件既可以是二進制文件，也可以是可執(zhí)行的腳本文件，兩者在加載時略有差別，這里主要分析二進制文件的運行。
2.2 do_execve()
在用戶態(tài)下調用execve()，引發(fā)系統(tǒng)中斷后，在內核態(tài)執(zhí)行的相應函數(shù)是do_sys_execve()，而do_sys_execve()會調用do_execve()函數(shù)。do_execve()首先會讀入可執(zhí)行文件，如果可執(zhí)行文件不存在，會報錯。然后對可執(zhí)行文件的權限進行檢查。
如果文件不是當前用戶是可執(zhí)行的，則execve()會返回-1,報permission denied的錯誤。否則繼續(xù)讀入運行可執(zhí)行文件時所需的信息(見struct linux_binprm)。
- Execve()->do_sys_execve()->do_execve()(check if file exist and if can be runed by current user)
2.3 search_binary_handler()
接著系統(tǒng)調用search_binary_handler()，根據(jù)可執(zhí)行文件的類型(如shell,a.out,ELF等)，查找到相應的處理函數(shù)(系統(tǒng)為每種文件類型創(chuàng)建了一個struct linux_binfmt，并把其串在一個鏈表上，執(zhí)行時遍歷這個鏈表，找到相應類型的結構。如果要自己定義一種可
執(zhí)行文件格式，也需要實現(xiàn)這么一個handler)。然后執(zhí)行相應的load_binary()函數(shù)開始加載可執(zhí)行文件。
2.4 load_elf_binary()
加載elf類型文件的handler是load_elf_binary()，它先讀入ELF文件的頭部，根據(jù)ELF文件的頭部信息讀入各種數(shù)據(jù)(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中函數(shù)foo(),在編譯的時候這個信息被放進了test這個ELF文件中，相應的語句也變成了call fakefoo()。當加載test的時候，知道foo()是一個外部調用,于是求助于動態(tài)鏈接器，加載userlib.so,解析foo()函數(shù)地址，然后讓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。
但是現(xiàn)代的動態(tài)鏈接器因為性能等原因都采用了延遲加載和延遲解析技術，延遲加載是動態(tài)連接庫在需要的時候才被加載到內存空間中(通過頁面異常機制)，延遲解析是指到動態(tài)鏈接庫(以加載)中的函數(shù)被調用的時候，才會去把這個函數(shù)的起始地址解析出來，供調用者使用。動態(tài)鏈接器的實現(xiàn)相當?shù)膹碗s，為了性能等原因，對堆棧的直接操作被大量使用。
