[導(dǎo)讀]因?yàn)閳D片比較大，微信公眾號(hào)上壓縮的比較厲害，所以很多細(xì)節(jié)都看不清了，我單獨(dú)傳了一份到github上，想要原版圖片的，可以點(diǎn)擊下方的閱讀原文，或者直接使用下面的鏈接，來(lái)訪問(wèn)github：https://github.com/wangyuntao/linux-kernel-illus...
因?yàn)閳D片比較大，微信公眾號(hào)上壓縮的比較厲害，所以很多細(xì)節(jié)都看不清了，我單獨(dú)傳了一份到github上，想要原版圖片的，可以點(diǎn)擊下方的閱讀原文，或者直接使用下面的鏈接，來(lái)訪問(wèn)github：
另外，精致全景圖系列文章，以及之后的linux內(nèi)核分析文章，我都會(huì)整理到這個(gè)github倉(cāng)庫(kù)里，歡迎大家star收藏。
相信很多同學(xué)都會(huì)有疑問(wèn)，一個(gè)程序是如何運(yùn)行起來(lái)的，為什么我們?cè)趕hell中執(zhí)行了一個(gè)程序，它的main函數(shù)就會(huì)被調(diào)用呢？在main函數(shù)被調(diào)用之前及之后，又經(jīng)歷了什么呢？
今天我們就來(lái)詳細(xì)的說(shuō)下這個(gè)問(wèn)題。
還是和之前一樣，我畫(huà)了一張程序運(yùn)行的全景圖，在上圖中，一個(gè)程序運(yùn)行所經(jīng)歷的代碼段，我都標(biāo)注了其所在的git倉(cāng)庫(kù)、源文件、及函數(shù)名，想要自己看源碼的，可以參考下上圖中的這些信息。
我們先從整體上講一下這張圖。
在linux下，我們一般都是通過(guò)shell來(lái)執(zhí)行程序的。
shell其實(shí)也是一個(gè)普通的程序，它也有自己的main函數(shù)，它在正常運(yùn)行后，會(huì)通過(guò)調(diào)用read_command函數(shù)，來(lái)等待用戶(hù)輸入命令。
在接收到用戶(hù)輸入的命令后，shell會(huì)先使用fork系統(tǒng)調(diào)用，創(chuàng)建一個(gè)子進(jìn)程，然后再在這個(gè)子進(jìn)程中，通過(guò)execve系統(tǒng)調(diào)用，執(zhí)行最終的用戶(hù)程序。
在子進(jìn)程執(zhí)行用戶(hù)程序期間，shell主進(jìn)程會(huì)調(diào)用waitpid函數(shù)，阻塞等待子進(jìn)程的完成，子進(jìn)程完成之后，waitpid從阻塞狀態(tài)中返回，且status參數(shù)中會(huì)帶著子進(jìn)程的退出碼，這個(gè)退出碼會(huì)在后續(xù)的邏輯中被保存起來(lái)，供用戶(hù)查詢(xún)。
之后，shell主進(jìn)程進(jìn)入到下一次循環(huán)，繼續(xù)等待用戶(hù)輸入命令并執(zhí)行。
以上就是shell的主體邏輯，對(duì)應(yīng)于上面全景圖中的藍(lán)色部分。
下面我們?cè)賮?lái)看下linux內(nèi)核中有關(guān)execve系統(tǒng)調(diào)用的代碼，也就是上面全景圖中的綠色部分。
shell通過(guò)execve系統(tǒng)調(diào)用，告知linux內(nèi)核，要在當(dāng)前進(jìn)程中執(zhí)行目標(biāo)程序，linux內(nèi)核經(jīng)過(guò)層層代碼，最終到達(dá)load_elf_binary函數(shù)。
該函數(shù)是整個(gè)系統(tǒng)調(diào)用中最核心的一段邏輯，它主要用來(lái)為目標(biāo)程序準(zhǔn)備各種執(zhí)行環(huán)境。
比如，映射代碼區(qū)、數(shù)據(jù)區(qū)等到當(dāng)前進(jìn)程的虛擬地址空間，將程序名、環(huán)境變量、程序參數(shù)、及各種其他數(shù)據(jù)，有規(guī)律的壓入到新分配的棧中，等等。
之后，load_elf_binary函數(shù)會(huì)調(diào)用start_thread，進(jìn)而會(huì)調(diào)用start_thread_common函數(shù)。
在該函數(shù)里，會(huì)將返回到用戶(hù)區(qū)之后，要執(zhí)行的，用戶(hù)區(qū)程序的起始地址，設(shè)置到regs->ip里，同時(shí)也會(huì)將上面新初始化好的，用戶(hù)堆棧的棧頂?shù)刂罚O(shè)置到regs->sp里。
當(dāng)execve系統(tǒng)調(diào)用返回到用戶(hù)區(qū)之后，regs->ip和regs->sp里的值，會(huì)分別賦值到rip和rsp寄存器里，這樣指定的用戶(hù)程序就可以繼續(xù)執(zhí)行了。
這一流程我們?cè)谥暗奈恼?精致全景圖 | 系統(tǒng)調(diào)用是如何實(shí)現(xiàn)的 中講過(guò)，這里就不再贅述。
不過(guò)這里還是有一點(diǎn)需要注意，就是設(shè)置到regs->ip中的地址，并不是我們自己程序的起始地址，而是動(dòng)態(tài)鏈接器 /lib64/ld-linux-x86-64.so.2 的起始地址。
之所以要設(shè)置動(dòng)態(tài)鏈接器的起始地址，是因?yàn)槲覀冃枰诜祷氐接脩?hù)區(qū)之后，讓其可以繼續(xù)為我們的程序準(zhǔn)備執(zhí)行環(huán)境，比如，幫忙加載程序依賴(lài)的各種動(dòng)態(tài)鏈接庫(kù)等。
在動(dòng)態(tài)鏈接器為我們的程序準(zhǔn)備好執(zhí)行環(huán)境之后，它會(huì)從進(jìn)程堆棧的auxiliary vector區(qū)，取出最終用戶(hù)程序的真正起始地址，并跳轉(zhuǎn)到該位置開(kāi)始執(zhí)行。
auxiliary vector區(qū)存放的用戶(hù)程序的起始地址，是上面linux內(nèi)核初始化堆棧時(shí)設(shè)置的。
動(dòng)態(tài)鏈接器相關(guān)的代碼就是這些，它對(duì)應(yīng)于上面全景圖中紫色的部分。
在跳轉(zhuǎn)到我們自己程序的起始地址后，首先執(zhí)行的并不是我們寫(xiě)的main函數(shù)，而是glibc里名為_(kāi)start的一段匯編代碼。
這段匯編代碼也比較簡(jiǎn)單，主要是從堆棧中獲取main函數(shù)所需的argc，argv等參數(shù)，然后最終調(diào)用我們寫(xiě)的main函數(shù)。
當(dāng)main函數(shù)返回之后，glibc里的后續(xù)代碼，會(huì)將main函數(shù)的返回值，當(dāng)作該進(jìn)程的退出碼，然后調(diào)用exit結(jié)束該進(jìn)程。
這些代碼對(duì)應(yīng)于上面全景圖中的粉色部分。
進(jìn)程調(diào)用exit退出之后，shell主進(jìn)程也會(huì)從waitpid的阻塞狀態(tài)中返回，然后繼續(xù)進(jìn)行下一次循環(huán)。
以上就是程序完整的啟動(dòng)和結(jié)束流程。
下面我們來(lái)看下具體的源碼實(shí)現(xiàn)。
注意，為了方便理解，很多代碼我們都做了刪減。
首先是shell部分，shell是一個(gè)普通的程序，它也有自己的main函數(shù)：
該函數(shù)里調(diào)用了reader_loop：
reader_loop的主體邏輯是，在while循環(huán)里不斷的使用read_command函數(shù)讀取用戶(hù)輸入的命令，然后使用execute_command執(zhí)行該命令。
execute_command函數(shù)經(jīng)過(guò)層層代碼后，會(huì)使用下圖中的fork，創(chuàng)建一個(gè)子進(jìn)程：
然后在該子進(jìn)程中，使用execve系統(tǒng)調(diào)用，告知linux內(nèi)核，用當(dāng)前子進(jìn)程執(zhí)行新的用戶(hù)程序：
在shell主進(jìn)程中，會(huì)調(diào)用waitpid函數(shù)，阻塞等待子進(jìn)程的完成：
當(dāng)子進(jìn)程退出后，waitpid會(huì)從阻塞狀態(tài)中返回，并在status里攜帶子進(jìn)程的退出碼，之后shell主進(jìn)程又返回上面的read_command函數(shù)，繼續(xù)等待用戶(hù)下一條命令的輸入。
以上就是bash的主體邏輯，對(duì)應(yīng)于上面全景圖中的藍(lán)色部分。
下面我們繼續(xù)看全景圖中的綠色部分，也就是linux內(nèi)核中有關(guān)execve的代碼。
當(dāng)shell的子進(jìn)程執(zhí)行execve函數(shù)時(shí)，linux內(nèi)核中對(duì)應(yīng)的系統(tǒng)調(diào)用被觸發(fā)：
沿著函數(shù)的調(diào)用鏈，我們會(huì)找到一個(gè)名為do_execveat_common的函數(shù)，在該函數(shù)中，會(huì)將目標(biāo)程序的文件名、環(huán)境變量、及各種程序參數(shù)等字符串，拷貝到新創(chuàng)建的用戶(hù)堆棧區(qū)：
此時(shí)，新創(chuàng)建的堆棧區(qū)里內(nèi)容，就如上面全景圖中右下角的a1-a9, b1-b8部分構(gòu)成的二維網(wǎng)格區(qū)域里所示的內(nèi)容。
其中，黃色區(qū)域里存放的是程序參數(shù) ./a.out hello world，藍(lán)色區(qū)域里存放的是環(huán)境變量 SHLVL=2, HOME=/, TERM=linux, PWD=/，橘黃色區(qū)域里存放的是要執(zhí)行的程序文件名 ./a.out。
這些內(nèi)容和我們執(zhí)行的測(cè)試程序，及其所處的環(huán)境也正好一樣：
繼續(xù)沿著內(nèi)核函數(shù)調(diào)用鏈，我們最終會(huì)來(lái)到load_elf_binary函數(shù)，該函數(shù)是整個(gè)系統(tǒng)調(diào)用的核心。
由于linux上執(zhí)行的程序基本上都是elf格式，所以?xún)?nèi)核選擇的加載函數(shù)是load_elf_binary，看這個(gè)函數(shù)時(shí)，可以參考elf格式的man文檔：
https://man.archlinux.org/man/elf.5
該函數(shù)比較復(fù)雜，我對(duì)其做了大量刪減，并添加了很多注釋?zhuān)?/span>
該函數(shù)最后會(huì)調(diào)用start_thread函數(shù)，進(jìn)而會(huì)調(diào)用start_thread_common函數(shù)：
這個(gè)函數(shù)重點(diǎn)需要注意的是對(duì)regs->ip和regs->sp的賦值，其作用在load_elf_binary函數(shù)的截圖中已經(jīng)注釋過(guò)了，就是在返回到用戶(hù)區(qū)之后，這兩個(gè)字段的值會(huì)被分別拷貝到rip和rsp寄存器里，所以這里的賦值，就相當(dāng)于在返回用戶(hù)區(qū)之后，對(duì)rip和rsp寄存器的賦值，這個(gè)在 精致全景圖 | 系統(tǒng)調(diào)用是如何實(shí)現(xiàn)的 有講。
到這里內(nèi)核部分的代碼就都已經(jīng)結(jié)束了。
由load_elf_binary函數(shù)截圖中可見(jiàn)，regs->ip中設(shè)置的地址是elf_entry，即動(dòng)態(tài)鏈接器的起始地址，而不是我們自己程序的起始地址。
原因是，我們還需要?jiǎng)討B(tài)鏈接器繼續(xù)幫我們準(zhǔn)備執(zhí)行環(huán)境，比如幫我們加載程序依賴(lài)的動(dòng)態(tài)鏈接庫(kù)等。
所以在execve系統(tǒng)調(diào)用返回到用戶(hù)區(qū)之后，代碼流程就進(jìn)入到了動(dòng)態(tài)鏈接器里的邏輯，即上面全景圖中的紫色區(qū)域：
上圖中的_start是動(dòng)態(tài)鏈接器的起始執(zhí)行地址，這個(gè)可以通過(guò)下面的方式來(lái)確認(rèn)：
在_start函數(shù)中，先將rsp寄存器的值，即上面內(nèi)核新初始化的堆棧的棧頂?shù)刂?，賦值到rdi中，然后再使用call指令，調(diào)用_dl_start函數(shù)。
之所以要賦值到rdi寄存器中，是因?yàn)閏語(yǔ)言的calling convention約定好的，用此方式來(lái)傳遞參數(shù)。
再看_dl_start函數(shù)：
該函數(shù)調(diào)用了_dl_start_final，返回一個(gè)地址，這個(gè)地址就是我們自己程序的起始地址。
再看_dl_start_final：
該函數(shù)又調(diào)用了_dl_sysdep_start：
在這里，動(dòng)態(tài)鏈接器通過(guò)內(nèi)核初始化的堆棧區(qū)中的auxiliary vector，找到最終用戶(hù)程序的起始執(zhí)行地址。
再之后，動(dòng)態(tài)鏈接器的函數(shù)調(diào)用鏈依次退出，最終返回到上面的_start函數(shù)。
_start函數(shù)之后會(huì)順序執(zhí)行_dl_start_user，相關(guān)代碼也在上面的_start函數(shù)的截圖里。
其邏輯是，先將rax中的值，即_dl_start函數(shù)返回的最終用戶(hù)程序的起始地址，賦值到r12寄存器中，然后再jmp到r12寄存器指向的地址，即開(kāi)始執(zhí)行最終的用戶(hù)程序邏輯。
至于rax中的值，為什么是_dl_start函數(shù)返回的地址，這個(gè)其實(shí)也是 c calling convention 中的約定，感興趣可以自己查下。
以上就是動(dòng)態(tài)鏈接器的全部邏輯，其對(duì)應(yīng)于全景圖中的紫色部分。
最后，邏輯進(jìn)入到了全景圖中的粉色部分。
動(dòng)態(tài)鏈接器從內(nèi)核設(shè)置的auxiliary vector中，獲取的用戶(hù)程序的起始地址，還并不是我們的main函數(shù)，而是glibc中一段名為_(kāi)start的代碼，這個(gè)可以通過(guò)下面的方式確認(rèn)：
該_start代碼段內(nèi)容如下：
它從堆棧中獲取到argc和argv，然后調(diào)用__libc_start_main：
在__libc_start_main里，才真正的調(diào)用了我們寫(xiě)的main函數(shù)。
當(dāng)main函數(shù)返回之后，__libc_start_main里用main函數(shù)返回的值，作為該進(jìn)程的退出碼，然后調(diào)用exit退出當(dāng)前進(jìn)程。
當(dāng)該進(jìn)程退出后，shell主進(jìn)程也從waitpid的阻塞狀態(tài)返回，并攜帶用戶(hù)程序的退出碼。
在上面全景圖這個(gè)示例中，返回碼為99：
之后，shell主進(jìn)程又進(jìn)入到下一次循環(huán)，繼續(xù)等待用戶(hù)命令并執(zhí)行，也就是說(shuō)，又進(jìn)入到全景圖中的藍(lán)色部分。
至此，在linux上執(zhí)行程序的流程，就形成了一個(gè)完整閉環(huán)。
你，學(xué)廢了嗎？
能看到這里的，都是真愛(ài)了，給個(gè)贊再走吧。
另外，沒(méi)有關(guān)注我公眾號(hào)的也可以關(guān)注下，一起來(lái)探索linux內(nèi)核里的神秘世界。
欲知詳情，請(qǐng)下載word文檔
下載文檔
本站聲明： 本文章由作者或相關(guān)機(jī)構(gòu)授權(quán)發(fā)布，目的在于傳遞更多信息，并不代表本站贊同其觀點(diǎn)，本站亦不保證或承諾內(nèi)容真實(shí)性等。需要轉(zhuǎn)載請(qǐng)聯(lián)系該專(zhuān)欄作者，如若文章內(nèi)容侵犯您的權(quán)益，請(qǐng)及時(shí)聯(lián)系本站刪除。
