[[356763]]

這個(gè)世界是紛繁復(fù)雜的，同時(shí)又是符合一些簡單規(guī)律的。朱子有句名言：千頭萬緒，終歸一理。意思是無論多么混亂的東西，都始終是由一個(gè)簡單的道理支配著的。舉例來說，在古老的《易經(jīng)》里便定義了陰陽兩個(gè)符號，并賦予了它們豐富而且深刻的內(nèi)涵。在《易經(jīng)》的系辭傳中，有一句著名的話：易有太極，是生兩儀。對這句話，有不同的理解。“天地起源說”是其中一種。根據(jù)這種理解，宇宙最初是混沌的一體，后來清者為天，濁者為地，這個(gè)形成天地的過程可以被簡稱為“二儀攸分”。

我不敢說這句話對描述天地形成有幾分準(zhǔn)確，但憑著多年來對軟件的研究，我認(rèn)為它對軟件世界是很適用的。最早的軟件就是一長串卡片，連在一起，卡片上的指令住在一個(gè)空間里，是平等的，沒有特權(quán)差異，沒有空間劃分。隨著計(jì)算機(jī)的發(fā)展，計(jì)算機(jī)系統(tǒng)里的角色開始細(xì)分，每個(gè)角色的特征和位置逐漸固定。于是有了中央化的內(nèi)存和處理器，以及外部的輸入輸出設(shè)備。

中央的處理器和內(nèi)存速度很快，外部的輸入輸出設(shè)備速度很慢。讓中央處理器直接與外設(shè)對話太影響效率了。于是便有了中斷的概念，中央處理器需要什么，下命令給外設(shè)，外設(shè)做好了，通過中斷通知中央處理器：“報(bào)告老大，您吩咐的任務(wù)完成了。”外部設(shè)備不止一個(gè)，中斷也有很多種，為了更好的處理中斷，便有了專門用于處理中斷的“控制程序”，這便是操作系統(tǒng)的前身。中斷處理程序的邏輯很敏感，如果出故障就會導(dǎo)致整個(gè)系統(tǒng)無法工作。既然它如此重要，那么就應(yīng)該“優(yōu)待”它，讓它享有特權(quán)，給它專門的“住所”，加強(qiáng)其住所的防衛(wèi)，防止有人擅自闖入。于是便有了專門給中斷處理程序住的空間，也就是所謂的內(nèi)核空間。有了高特權(quán)的內(nèi)核空間后，也就有了低特權(quán)的用戶空間。于是本來混沌一體不分特權(quán)的軟件世界便分成兩個(gè)部分了。

在軟件世界的兩個(gè)空間中，“用戶空間是可見的，很多程序在上面生生不息，屬陽。內(nèi)核空間不可見，但是承載著上面的應(yīng)用，為應(yīng)用提供服務(wù)，厚德載物，本身不發(fā)光，但是卻能反射應(yīng)用的光輝，像月亮，屬陰。”(選自《軟件調(diào)試》卷2)今天，軟件世界的這種基本格局已經(jīng)非常固定，無論是Windows，還是Linux都是如此。用戶空間和內(nèi)核空間的關(guān)系與現(xiàn)實(shí)世界中公民與政府的公司非常類似。當(dāng)公民需要政府服務(wù)時(shí)要到政府的窗口去辦理，軟件世界中的對應(yīng)機(jī)制便叫“系統(tǒng)調(diào)用”，意思是要調(diào)用系統(tǒng)的服務(wù)。

[前半部分為科普，后半部分換擋，前方高寒，非geek止步]

受兩大空間劃分的影響，當(dāng)我們調(diào)試軟件時(shí)，一般也分為調(diào)試用戶空間代碼的應(yīng)用程序調(diào)試，和調(diào)試內(nèi)核空間代碼的內(nèi)核調(diào)試。相應(yīng)的，調(diào)試器也可以分為應(yīng)用程序調(diào)試器和內(nèi)核調(diào)試器。

容易理解，當(dāng)我們使用應(yīng)用程序調(diào)試器調(diào)試應(yīng)用程序時(shí)，是無法調(diào)試內(nèi)核代碼的。反過來則未必。

或者說，使用內(nèi)核調(diào)試器能調(diào)試用戶空間的代碼嗎?

理論上是可以的，因?yàn)閮?nèi)核空間的特權(quán)高，既然已經(jīng)能訪問和控制內(nèi)核空間，那么理論也就能訪問和控制受內(nèi)核管理的用戶空間。

理論上可以，實(shí)踐中可以么?答案是未必，要看調(diào)試器的能力，也要看調(diào)試者的技術(shù)水平。

舉例來說，使用WinDBG來調(diào)試Windows內(nèi)核時(shí)，也可以在用戶空間設(shè)置斷點(diǎn)，斷點(diǎn)命中后，可以讀寫變量，或者單步跟蹤。

不過，雖然WinDBG有這個(gè)能力，實(shí)際能做把WinDBG使用到這個(gè)程度的人其實(shí)并不多。在這方面，WinDBG還有一個(gè)非常牛的能力，那就是跨越陰陽二界地顯示系統(tǒng)調(diào)用的完整過程，比如：

在上面這幅完美的?；厮葜?，下面部分是CPU在用戶空間的執(zhí)行經(jīng)過，從線程的起點(diǎn)開始，到AfxWinMain，經(jīng)過消息循環(huán)，然后是OLE的處理文件拖拽邏輯，收到一個(gè)文件后，自己不認(rèn)識，通過古老的DDE機(jī)制廣播消息尋求幫助，用于廣播消息的SendMessageW函數(shù)發(fā)起系統(tǒng)調(diào)用，進(jìn)入內(nèi)核空間，內(nèi)核空間中的Win32K模塊處理這個(gè)服務(wù)請求，執(zhí)行廣播消息的任務(wù)，把消息發(fā)個(gè)一個(gè)個(gè)頂層窗口，遇到一個(gè)“收到消息不回的壞蛋”，卡在那里了。

我第一次看到這樣的完美棧回溯時(shí)，我深深被微軟調(diào)試工具的技術(shù)水平所打動。

為什么呢?因?yàn)橐缭絻蓚€(gè)空間顯示這個(gè)?；厮萦泻芏嗬щy。第一個(gè)困難是每個(gè)普通線程都至少有兩個(gè)棧，用戶空間一個(gè)，內(nèi)核空間一個(gè)，因此，要顯示上面這樣的完美棧回溯，必須要回溯兩個(gè)棧，因?yàn)槠瘘c(diǎn)在內(nèi)核空間，因此，內(nèi)核空間的棧比較好找。但用戶空間的棧位置就不那么好找。

第二個(gè)困難是今天的主流操作系統(tǒng)都是多任務(wù)的，有很多個(gè)用戶空間，要顯示上面的完美棧回溯，必須要找到正確的用戶空間，并且找到這個(gè)空間中的模塊列表，加載用戶空間的模塊。

自從開始開發(fā)NDB調(diào)試器，我就想讓它也具有“產(chǎn)生完美?；厮?rdquo;的能力。為了實(shí)現(xiàn)這個(gè)愿望，我花很多時(shí)間思考，加上很多時(shí)間寫代碼，當(dāng)然還花了很多時(shí)間來調(diào)試代碼，讓它如預(yù)期的工作。

長話短說，解決第一個(gè)困難花了至少三十個(gè)小時(shí)的時(shí)間。最終的成功方案是要經(jīng)歷這幾個(gè)步驟。先通過內(nèi)核空間的?；厮荩业紺PU做系統(tǒng)調(diào)用時(shí)，飛到內(nèi)核空間的起點(diǎn)，在x64下，它是使用匯編編寫的entry_SYSCALL_64。在內(nèi)核源碼的syscall_init中，也可以看到這個(gè)證據(jù)。

entry_SYSCALL_64的源代碼位于：F:\bench\linux-5.0.7\arch\x86\entry\entry_64.S在這個(gè)非常值得細(xì)讀的匯編源文件中，有一段很長的注釋，這段注釋幫了我大忙。

更重要的是，在這個(gè)匯編函數(shù)中，它保存了一個(gè)所謂的硬件幀，通過不斷壓棧，在棧上形成形成了一個(gè)pt_regs結(jié)構(gòu)體。

這個(gè)pt_regs結(jié)構(gòu)體里面包含了關(guān)鍵的寄存器信息，特別是我需要的用戶空間棧指針rsp。

類比一下，這個(gè)結(jié)構(gòu)體相當(dāng)于Windows下的陷阱幀(KTRAP_FRAME)，這又應(yīng)了朱子的話：千頭萬緒，終歸一理。

在征戰(zhàn)這一關(guān)時(shí)，我的NDB發(fā)揮了很大作用，比如我在entry_SYSCALL_64入口設(shè)置斷點(diǎn)，成功命中，這讓我可以清楚觀察CPU從用戶空間飛到內(nèi)核空間后剛剛著陸后的精確狀態(tài)，每個(gè)寄存器的取值。

rax=00000000000000e4 rbx=0000000000000001rcx=00007ffdc513099a // RIP 
rdx=00007f9b9dec9e10 rsi=00007f9b9dec9e10rdi=0000000000000001 
rip=ffffffffa3e00010 rsp=00007f9b9dec9db8rbp=00007f9b9dec9dc0 
 r8=0000000000000000  r9=00007f9b9dec9e10 r10=00007f9b9dec9db0 
r11=0000000000000286 r12=00007f9b9dec9e10r13=0000000000000000 
r14=00007f9b9dec9e10 r15=00007f9b9dec9e20 
iopl=0         nv up di ng nz na po nc 
cs=0010 ss=0018  ds=0000  es=0000 fs=0000  gs=0000             efl=00010086 
lk!entry_SYSCALL_64: 
ffffffff`a3e00010 0f01f8        invlpg eaxds:0010:00007ffd`c512d080=00126362 

其中rcx寄存器的值便是用戶空間的程序指針，因?yàn)楦鶕?jù)SYSCALL指令的定義，CPU會把rip保存到rcx，即上面注釋中說的：

64-bit SYSCALL saves rip to rcx使用NDB反匯編這個(gè)值-2(減2是為了看到已經(jīng)執(zhí)行過的syscall指令)便可以看到用戶空間發(fā)起系統(tǒng)調(diào)用的指令：

u 007ffdc5130998 
00007ffd`c5130998 0f05             syscall 
00007ffd`c513099a 415c             pop    r12d 
00007ffd`c513099c 5d               pop     rbp 
00007ffd`c513099d c3               ret 
00007ffd`c513099e a860             test    al,0x60 
00007ffd`c51309a0 7438             jz      00007ffdc51309da 
00007ffd`c51309a2 4863c7           movsxd  rax,edi 
00007ffd`c51309a5 488d0dd4c6ffff   lea    rcx,[00007ffdc512d080] 

順便說一下，使用匯編語言編寫的entry_SYSCALL_64函數(shù)準(zhǔn)備pt_regs結(jié)構(gòu)體的目的是為了給使用C語言編寫的do_syscall_64函數(shù)準(zhǔn)備參數(shù)。后者的第二個(gè)參數(shù)便是指向pt_regs結(jié)構(gòu)體的指針，即：

__visible void do_syscall_64(unsigned long nr, struct pt_regs *regs) 

下面是準(zhǔn)備調(diào)用C語言函數(shù)前的寄存器上下文：

和棧數(shù)據(jù)：

對于這個(gè)棧數(shù)據(jù)，不常做底層調(diào)試的同行可能滿臉問號。對于我來說，幾乎每個(gè)字節(jié)都非常親切，像老朋友一樣，因?yàn)樗鼈兌紓€(gè)性鮮明，16位的段選擇子也住著64位的大房子(^-^)。

對于第二個(gè)困難，解決的難度更大，主要的步驟如下。

首先要通過per-cpu區(qū)找到當(dāng)前任務(wù)指針，也就是current指針，參見我的上一篇文章。然后要通過current指針找到當(dāng)前任務(wù)的地址空間描述，也就是mm_struct。然后找到mm_struct中的VMA鏈表，再遍歷這個(gè)鏈表，篩選出其中的一個(gè)個(gè)so模塊描述。

找到這些so模塊描述后，還需要把這些描述報(bào)告給調(diào)試引擎，讓調(diào)試引擎來加載用戶空間的模塊。

找到用戶空間的棧和加載了用戶空間的模塊后，再觀察?；厮荩憧梢钥吹较Ｍ氖锕饬?。比如下面是11月21日時(shí)看到的場景：

已經(jīng)看到libc和著名的ld模塊，這給我很大鼓勵(lì)。

仔細(xì)觀察上面這個(gè)棧回溯，容易看出libc中的函數(shù)名很不精確，用調(diào)試器分析，發(fā)現(xiàn)使用的libc符號文件缺少對?；厮葜陵P(guān)重要的幀信息。深究原因，讓人暈倒。與Windows下的符號文件不同，Linux(以Ubuntu為例)的gcc編譯時(shí)如果有-g選項(xiàng)，則會產(chǎn)生調(diào)試符號，與執(zhí)行信息放在一個(gè)文件中。

包含符號信息的文件比較大，所以一般會通過所謂的strip過程產(chǎn)生一個(gè)消減符號的產(chǎn)品文件和一個(gè)用于調(diào)試的符號文件。比如使用下面這樣的objcopy命令便可以產(chǎn)生一個(gè)專門用作調(diào)試的符號文件：

gedu@gedu-VirtualBox:~/labs/gemalloc$ readelf --debug-dump=frames gemalloc.dbg 
section '.eh_frame' has the NOBITS type - its contents are unreliable. 

用下面兩條命令則可以產(chǎn)生一個(gè)適于發(fā)布到產(chǎn)品環(huán)境的不帶符號版本：

gedu@gedu-VirtualBox:~/labs/gemalloc$ cp gemalloc gemalloc.prd 
gedu@gedu-VirtualBox:~/labs/gemalloc$ objcopy --strip-debug  gemalloc.prd 

觀察文件大小，是有明顯差異的：

調(diào)試時(shí)，我們一般使用符號文件。因?yàn)榇蠖鄶?shù)符號信息是放在符號文件中的。注意，這里是說大多數(shù)，并不是全部。比如幀信息，因?yàn)榘l(fā)生異常時(shí)做棧展開也需要，所以幀信息是放在產(chǎn)品文件中的。既然幀信息對于調(diào)試和正常執(zhí)行都需要，按說應(yīng)該兩個(gè)文件都有一份，但事實(shí)上不是，至少上面截圖中使用的libc符號文件里不包含幀信息，節(jié)的頭仍在，但是標(biāo)志位里有NOBITS標(biāo)志，代表這個(gè)節(jié)的數(shù)據(jù)是不可靠的，解析時(shí)會失敗。

比如，使用readelf命令來顯示上面產(chǎn)生符號文件的幀信息，會得到如下提示：

gedu@gedu-VirtualBox:~/labs/gemalloc$ readelf --debug-dump=frames gemalloc.dbg 
section '.eh_frame' has the NOBITS type - its contents are unreliable. 

再附加個(gè)截圖吧：

以下是readelf程序的有關(guān)源代碼：

if(section->sh_type == SHT_NOBITS) 
   { 
    /* There is no point in dumping the contents of a debugging section 
       which has the NOBITS type - the bits in thefile will be random. 
       This can happen when a file containing a.eh_frame section is 
       stripped with the --only-keep-debug commandline option.  */ 
    printf (_("section '%s' has the NOBITS type - its contents are unreliable.\n"), 
            print_name); 
    return 0; 

怎么解決這個(gè)問題呢?就是要讓NDB為一個(gè)模塊加載兩個(gè)符號文件。細(xì)節(jié)從略。

過了這一個(gè)難關(guān)后，便可以看到更好一些的?；厮萘?。libc的函數(shù)名變得很精確。

仔細(xì)觀察上面的結(jié)果，美中不足的是最后三行，有兩行重復(fù)clone函數(shù)，最后一行沒有給出函數(shù)名，也沒有顯示出代表root的返回地址為0特征。

他山之石可以攻玉。使用gdb來做對比較實(shí)驗(yàn)，看到的是：

(gdb) bt 
#0  thread_func (arg=0x9) at gemalloc.c:289 
#1  0x00007ffff68216ba in start_thread(arg=0x7fffc6ffd700) 
    at pthread_create.c:333 
#2  0x00007ffff655741d in clone () 
    at../sysdeps/unix/sysv/linux/x86_64/clone.S:109 

看來clone函數(shù)確實(shí)是線程的起點(diǎn)。gdb成功在起點(diǎn)處停車?？墒莕db沒有。

給調(diào)試器上調(diào)試器，調(diào)試NDB。仔細(xì)跟蹤負(fù)責(zé)解析符號的ndw模塊。

跟蹤發(fā)現(xiàn)，ndw可以順利找到clone函數(shù)的幀信息，即：

000146e80000000000000014 00000000 CIE 
  Version:               1 
  Augmentation:          "zR" 
  Code alignment factor: 1 
  Data alignment factor: -8 
  Return address column: 16 
  Augmentation data:     1b 
  DW_CFA_def_cfa: r7 (rsp) ofs 8 
  DW_CFA_offset: r16 (rip) at cfa-8 

DW_CFA_undefined:r16 (rip)

上面的DW_XX是DWARF標(biāo)準(zhǔn)里定義的棧回溯指令，可以理解為腳本語言。NDW內(nèi)部的解釋器順利執(zhí)行了前兩條語句：

DW_CFA_def_cfa: r7 (rsp) ofs 8 
  DW_CFA_offset: r16 (rip) at cfa-8 

但是在執(zhí)行第三條語句時(shí)，懵圈了。

DW_CFA_undefined:r16 (rip)

我在跟蹤這條語句對應(yīng)的解釋器代碼時(shí)，以為遇到了不認(rèn)識的指令，推測是版本兼容導(dǎo)致的。

反復(fù)跟蹤和思索了很久，我終于領(lǐng)悟到了，這個(gè)undefined并不是我最初想的那樣。它的含義不是說它是一條未定義的指令，而是要把它的操作數(shù)，也就是后面的rip寄存器設(shè)置為“未定義”狀態(tài)。

某種程度來說，?；厮菥褪窃诨貪L寄存器的狀態(tài)，而這個(gè)

DW_CFA_undefined:r16 (rip)

就是要把rip寄存器的狀態(tài)回滾到“未定義狀態(tài)”。也就是讓它進(jìn)入一個(gè)不知道為何值的狀態(tài)。

在NDW的老代碼中，對于這個(gè)情況，會把rip回滾到它的當(dāng)前值(也就是不回滾)，于是就出現(xiàn)了上面的clone函數(shù)的父函數(shù)還是clone函數(shù)的現(xiàn)象。

閱讀libc中clone函數(shù)的源代碼，可以找到這個(gè)DW_CFA_undefined指令的來源，是某位同行故意手工加入的。

代碼中的注釋很有意思：故意加了這個(gè)undefined來標(biāo)記到了最外層的棧幀，非常明顯地!其實(shí)不加就挺好的。Anyway，也是用心良苦。

閉目思索，這里用的undefined也非常具有哲學(xué)意味。很多時(shí)候我們在尋找源頭，可是最終的源頭到底在哪里呢?我們找到的源頭也未必就是真的源頭。真的源頭常常是未知的，也就是undefined。比如2020年的新冠病毒，人類能找到真的源頭么?至少到今天，還是undefined。

如此想來，這種在線程源頭標(biāo)記為undefined的方法還真是意義非凡。

找到根源之后，我直接把這種undefined的回滾處理成回滾到0，問題便解決了，夢寐以求的完美棧回溯出現(xiàn)在眼前。

本文轉(zhuǎn)載自微信公眾號「格友」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系格友公眾號。