可執行文件是怎么來的？（以C語言為例）

C代碼（.c） - 經過編譯器預處理，編譯成匯編代碼（.asm） - 匯編器，生成目標代碼（.o） - 鏈接器，鏈接成可執行文件（.out） - OS將可執行文件加載到內存里執行

From C to running program

Compiler, assembler, linker, and loader

可執行文件的創建

#include <stdio.h>

int main()
{
	printf("hello world!\n");
}

1. 預處理
gcc -E -o hello.cpp hello.c -m32??? 預處理（文本文件）
預處理負責把include的文件包含進來及宏替換等工作

2. 編譯
gcc -x cpp-output -S -o hello.s hello.cpp -m32??? 編譯成匯編代碼（文本文件）

3. 匯編
gcc -x assembler -c hello.s -o hello.o -m32??? 匯編成目標代碼（ELF格式，二進制文件，有一些機器指令，只是還不能運行）

4. 鏈接
gcc -o hello hello.o -m32??? 鏈接成可執行文件（ELF格式，二進制文件）
在hello可執行文件里面使用了共享庫，會調用printf，libc庫里的函數
gcc -o hello.static hello.o -m32 -static??? 靜態鏈接
把執行所需要依賴的東西都放在程序內部

ls -l

hello 只有7k，hello.static卻有7百k，因為它把需要C庫里邊的東西也放到可執行文件里面來

可執行文件怎樣變成一個運行的進程的？

要弄清楚這個問題，需要先弄清楚，可執行文件的內部是怎樣的？是怎樣描述可執行文件的？

常見的文件格式

常見的文件格式

目標文件的格式ELF

EXECUTABLE? AND? LINKABLE? FORMAT? 可執行的和可鏈接的格式（是文件格式的標準）

.o文件 和 可執行文件，都是目標文件，一般使用相同的文件格式

ABI和目標文件格式是什么關系

目標文件也叫做ABI，應用程序二進制接口。實際上在目標文件里面，它已經是二進制兼容的格式。而什么叫二進制兼容呢？所謂的二進制兼容，就是指這個目標文件已經是適應某一種CPU體系結構上的二進制的指令，比如在32位x86環境下編譯出來的目標文件，鏈接成ARM上的可執行文件，那肯定是不可以的

ELF文件里面三種目標文件

一個可重定位（relocatable）文件保存著代碼和適當的數據，用來和其它的object文件一起來創建一個可執行文件或者是一個共享文件（主要是.o文件）

一個可執行（executable）文件保存著一個用來執行的程序，該文件指出了exec(BA_OS)如何來創建程序進程映象（操作系統怎么樣把可執行文件加載起來并且從哪里開始執行）

一個共享object文件保存著代碼和合適的數據，用來被下面兩個鏈接器鏈接：（主要是.so文件）
第一個是鏈接編輯器（靜態鏈接）【請參看ld(SD_CMD)】，可以和其它的可重定位和共享object文件來創建其它的object
第二個是動態鏈接器，聯合一個可執行文件和其它的共享object文件來創建一個進程映象

ELF的目標文件格式

Object文件參與程序的鏈接（創建一個程序）和程序的執行（運行一個程序）

Object File Format

一個ELF頭在文件的開始，保存了路線圖（road map），描述了該文件的組織情況
程序頭表（Program header table）告訴系統如何來創建一個進程的內存映像
Section頭表（Section header table）包含了描述文件Sections的信息。每個Section在這個表中有一個入口，每個入口給出了該Section的名字，大小等信息

鏈接視圖，有很多Section，執行視圖，有很多段（Segment）

大多數文件格式也都是這種模式，在頭記錄了一些元數據，用readelf命令來詳細查看ELF文件頭

用readelf命令來詳細查看ELF文件頭

可執行程序加載的主要工作

當創建或增加一個進程映象的時候，系統在理論上將拷貝一個文件的段到一個虛擬的內存段

Executable File

可執行文件的格式和進程的地址空間有一個映射關系

靜態鏈接的ELF可執行文件與進程的地址空間

可執行文件有一個頭部，里面有一些關鍵信息，Entry point Address，入口地址，即程序的起點，0x8048300，后面有一些代碼，數據

對于進程來講，進程有一個進程地址空間，而對于32位x86體系結構來講，進程有4G的進程地址空間（邏輯地址），3G以上的地址空間只能在內核態下訪問，在用戶態的時候，只能訪問0到3G的地址空間。

ELF可執行文件加載到內存的位置? 與? ELF可執行文件加載到內存中開始執行的第一行代碼

ELF可執行文件默認加載到內存0x8048000這個位置，從這個位置開始加載。前面加載ELF可執行文件的頭部信息，但因不同文件大小不同，程序的實際入口為：0x8048x00，圖例為0x8048300，也就是說這個位置是程序的實際入口地址，即剛加載過可執行文件的進程（一個進程加載了新的可執行文件之后，開始執行的入口點），就是從這個地方開始執行

簡略地來看，圖例里的文件是ELF的靜態鏈接文件。靜態鏈接的時候，會將所有代碼放在一個代碼段，把所有的鏈接都鏈接好了，所以從0x8048300開始一行行代碼執行，壓棧出棧，把整個程序執行完

而實際上如果需要用到共享庫，需要動態鏈接的話，會有多個代碼段，情況會更復雜（暫不研究）

裝載可執行程序之前的工作最主要的是兩大部分：

1. 可執行程序的文件格式
2. 可執行程序的執行環境

一般是通過shell程序啟動一個可執行程序，shell程序具體做了什么？而當啟動加載一個可執行程序的時候，也就是發起一個系統調用execve，shell環境準備了哪些執行的上下文環境（用戶態的執行環境）

再看看execve系統調用怎么樣把一個可執行文件在內核態里面裝載起來，裝載起來后又返回到用戶態（內核態的執行環境）

可執行程序的執行環境（Shell命令行、main函數的參數與execve的參數）

$ ls -l /usr/bin 列出/usr/bin下的目錄信息，Shell本身不限制命令行參數的個數，命令行參數的個數受限于命令自身
例如，int main(int argc, char *argv[])??? -- 愿意接收命令行參數
又如，int main(int argc, char *argv[], char *envp[])??? -- 愿意接收shell的環境變量，前兩個參數由用戶輸入命令的時候設定-l /usr/bin，后一個是shell環境，shell程序自動加上

Shell會調用execve將命令行參數和環境參數傳遞給可執行程序的main函數
int execve(const char * filename,char * const argv[ ],char * const envp[ ]);
庫函數exec*都是execve的封裝例程

小程序

命令行參數和環境變量是如何保存和傳遞的？

先函數調用參數傳遞，再系統調用參數傳遞

Shell程序 -> execve -> sys_execve，然后在初始化新程序堆棧時拷貝進去

命令行參數和環境串都放在用戶態堆棧中

命令行參數和環境串都放在用戶態堆棧中

當fork一個子進程的時候，復制父進程，調用execve系統調用的時候，要加載的可執行程序把原來的進程的環境覆蓋掉了，覆蓋掉之后它的用戶態堆棧也被清空了，因為它是個新的程序要執行，那么argv和envp是如何進入新程序的用戶態堆棧的？即命令行參數和環境變量是如何進入新程序的堆棧的？

在創建一個新的用戶態堆棧的時候，實際上是把命令行參數的內容和環境變量的內容通過指針的方式傳遞到execve系統調用的內核處理函數，然后內核處理函數在創建可執行程序新的用戶態堆棧的時候，會把參數拷貝到用戶態堆棧里，初始化新的可執行程序的上下文環境。所以，新的程序能從main函數開始，把對應的參數接收過來，然后執行。但原先在調用execve時，參數只是壓在了shell程序當前進程的堆棧上，而這個堆棧在加載完新的可執行程序之后，已經被清空了，內核又創建了一個新進程的用戶態堆棧

如果僅僅只是加載一個靜態鏈接的可執行程序的話，只需要傳遞一些命令行參數，一些環境變量，可執行程序就可以正常地工作。但是對于絕大多數的可執行程序來講，還有一些對動態鏈接庫的依賴，這個比較復雜。裝載時動態鏈接和運行時動態鏈接應用舉例

動態鏈接分為可執行程序裝載時動態鏈接和運行時動態鏈接，如下代碼演示了這兩種動態鏈接。

1. 準備.so文件（動態鏈接文件，windows下是dll）

shlibexample.h (1.3 KB) - Interface of Shared Lib Example

shlibexample.c (1.2 KB) - Implement of Shared Lib Example

編譯成libshlibexample.so文件

$ gcc -shared shlibexample.c -o libshlibexample.so -m32

dllibexample.h (1.3 KB) - Interface of Dynamical Loading Lib Example

dllibexample.c (1.3 KB) - Implement of Dynamical Loading Lib Example

編譯成libdllibexample.so文件

$ gcc -shared dllibexample.c -o libdllibexample.so -m32

2. 以共享庫和動態加載共享庫的方式使用libshlibexample.so文件和libdllibexample.so文件

main.c? (1.9 KB) - Main program

編譯main，注意這里只提供shlibexample的-L（庫對應的接口頭文件所在目錄）和-l（庫名，如libshlibexample.so去掉lib和.so的部分），并沒有提供dllibexample的相關信息，只是指明了-ldl

編譯、運行

可執行程序的裝載相關關鍵問題分析（execve和fork都是特殊一點的系統調用）

傳統的系統調用都是陷入到內核態，然后再返回到用戶態，繼續執行系統調用下面的指令

fork系統調用進入到內核態，兩次返回，在父進程中，返回到父進程原來的位置繼續向下執行，這個和傳統的系統調用是一樣的。在子進程中，構造了它的堆棧環境，子進程返回到特定的點，是從ret_from_fork開始執行然后返回到用戶態，對于子進程來講比較特殊

execve系統調用，當前的可執行程序在執行，執行到execve系統調用時候，陷入到內核態，在內核里面，用execve加載的可執行文件，把當前進程的可執行程序給覆蓋掉了，當execve系統調用返回的時候，已經不是返回到原來的可執行程序了，是新的可執行程序的執行起點，也就是main函數大致的位置，那么main函數的執行環境，也就需要我們來構建好加載的新的可執行程序的執行環境

sys_execve內核處理過程

當execve系統調用陷入到內核里的時候，system_call，調用了sys_execve()，sys_execve內部會解析可執行文件格式，后面的調用順序：
do_execve -> do_execve_common ->? exec_binprm

search_binary_handler根據文件頭部信息尋找對應的文件格式處理模塊，如下：

被觀察者

根據我們給出的文件名，加載了文件的頭部，判斷文件是什么格式，在列表中尋找能夠解釋ELF格式的內核模塊

對于ELF格式的可執行文件fmt->load_binary(bprm);執行的應該是load_elf_binary其內部是和ELF文件格式解析的部分需要和ELF文件格式標準結合起來閱讀

Linux內核是如何支持多種不同的可執行文件格式的？?

觀察者

觀察者

當ELF文件格式出現的時候，觀察者就能自動執行load_elf_binary，但實際上是在retval = fmt->load_binary(bprm)執行，這個地方實際上是一種多態的機制，本質上是一種觀察者模式

在load_elf_binary里有一個很關鍵的地方，start_thread

看一下start_thread????? /linux-3.18.6/fs/binfmt_elf.c#82

start_thread

start_thread這個函數有一個pt_regs，一個new_ip，一個new_sp
pt_regs實際上就是內核堆棧的棧底的那部分，發生系統調用int 0x80的時候，把eflags、sp、ip都壓入到棧。那么新進程執行的時候，需要把它的起點位置給它替換掉

新進程執行的時候，需要把起點位置替換掉

new_ip是怎么來的呢？

看一下load_elf_binary????? /linux-3.18.6/fs/binfmt_elf.c#571

975	start_thread(regs, elf_entry, bprm->p);

elf_entry，對于一個靜態鏈接的可執行文件，就是可執行文件里的Entry point address，可執行文件頭部定義的起點

在一個新的可執行程序返回到用戶態之前，需要修改int 0x80壓入內核堆棧的EIP，用新的可執行程序的起點來修改，但是對于動態鏈接的過程又更復雜一些，先理解靜態鏈接的過程，大致是這樣

看一下系統調用sys_execve內核處理過程

看一下sys_execve????? /linux-3.18.6/fs/exec.c#1604

入口

看一下do_execve????? /linux-3.18.6/fs/exec.c#do_execve

do_execve

看一下do_execve_common????? /linux-3.18.6/fs/exec.c#do_execve_common

打開要加載的可執行文件，然后加載文件頭部

1474	file = do_open_exec(filename);

創建結構體，bprm

1481	bprm->file = file;
1482	bprm->filename = bprm->interp = filename->name;

把環境變量和參數都copy到結構體里面

1505	retval = copy_strings(bprm->envc, envp, bprm);

1509	retval = copy_strings(bprm->argc, argv, bprm);

對可執行文件的處理過程

1513	retval = exec_binprm(bprm);

看一下exec_binprm????? /linux-3.18.6/fs/exec.c#exec_binprm

尋找可執行文件的處理函數

1416	ret = search_binary_handler(bprm);

看一下search_binary_handler????? /linux-3.18.6/fs/exec.c#1352

尋找能夠解釋當前可執行文件的代碼模塊

尋找能夠解釋當前可執行文件的代碼模塊

看一下load_elf_binary????? /linux-3.18.6/fs/binfmt_elf.c#84

結構體變量，對load_binary做了賦值

觀察者

前面說過，elf_format這個結構體變量要注冊到鏈表里面去，這是一個發布訂閱的架構模式，或者叫觀察者模式，實際上是一個函數指針，在面向對象里，叫多態模式

在看load_elf_binary之前，看elf_format這個結構體變量是怎么進入到一個內核的處理模塊里

看一下__init init_elf_binfmt????? /linux-3.18.6/fs/binfmt_elf.c#2198

觀察者

注冊結構體變量，把結構體變量注冊到鏈表里面去，這樣當出現一個ELF格式文件的時候，就到鏈表里面找專門處理ELF文件格式的模塊

重點關注ELF文件格式的解釋，看一下load_elf_binary????? /linux-3.18.6/fs/binfmt_elf.c#571

571static int load_elf_binary(struct linux_binprm *bprm)

（結合ELF文件格式）讀取文件頭部信息

626	retval = kernel_read(bprm->file, loc->elf_ex.e_phoff,
627			     (char *)elf_phdata, size);

load_elf_binary主要的工作是把可執行文件映射到進程的地址空間，ELF可執行文件默認會被映射到0x8048000這個地址

816		error = elf_map(bprm->file, load_bias + vaddr, elf_ppnt,
817				elf_prot, elf_flags, 0);

需要動態鏈接的可執行文件先加載連接器ld

需要動態鏈接的可執行文件先加載連接器ld

所以后面在start_thread的時候就會有兩種可能

975	start_thread(regs, elf_entry, bprm->p);

如果是一個靜態鏈接文件的話，elf_entry就是指向Entry point address的位置0x8048x00
如果是一個需要依賴動態鏈接庫的話，需要ld鏈接器，elf_entry就是指向動態鏈接器的起點

可以簡單地理解，start_thread實際上就是把返回到用戶態的位置從原來的int0x80的下一條指令變成了新加載的可執行文件的Entry point address的位置0x8048x00

淺析動態鏈接的可執行程序的裝載

對于一般的可執行程序來講，大多都是需要使用動態鏈接庫，動態鏈接庫最常見的就是libc，動態鏈接器ld它也是libc的一部分。那么在動態鏈接的過程，內核做了什么？

ELF格式里面要依賴其它的動態鏈接庫，動態鏈接庫某一個.so本身（它也是一個ELF格式的文件）還可能會依賴其它的動態鏈接庫，因此實際上動態鏈接庫的依賴關系會形成一個圖。在解釋每一個ELF格式文件的時候，看它依賴了哪些動態鏈接庫，這樣它就會加載

那么誰負責加載呢？

閱讀內核代碼的時候，可以看到，當這個文件需要用elf_interpreter的話，也就是說它需要依賴動態鏈接器來解釋這個ELF文件，那么它就需要加載load_elf_interp，實際上是加載動態連接器ld，那么這時候Entry point address，也就是說在返回到用戶態的時候，它返回的就不是這個可執行程序文件規定的起點，它返回的是動態連接器的程序入口，動態連接器負責解釋當前的可執行文件，看它里面依賴哪些動態鏈接庫，然后把那些動態鏈接庫一個一個加載進來，加載進來之后再解釋加載進來的動態鏈接庫，看它這個動態鏈接庫還依賴哪些文件，這樣就有一個叫廣度遍歷的方法（即動態鏈接庫的裝載過程是一個圖的遍歷），把所有的動態鏈接庫都裝載起來，裝載起來之后ld再負責把CPU的控制權移交給可執行程序頭部規定的起點位置

那么從以上分析看出，動態鏈接的過程不是由內核來完成的，主要是由動態鏈接器來完成的，動態鏈接器是libc的一部分，是在用戶態做的事情

Summary：

加載可執行程序兩種方式

1. 靜態鏈接，直接執行可執行程序的入口 Entry point address（0x8048x00）
2. 需要動態鏈接，由ld動態鏈接這個可執行程序

（完）