言入門：從寄存器、指令集到編譯器底層實(shí)現(xiàn))
學(xué)編程這些年我見過太多人一聽到“匯編語(yǔ)言”這四個(gè)字就頭皮發(fā)麻。在很多教材和課程里它往往被安排到第二章——講完基本概念之后第一道需要真正面向底層的大門。說實(shí)話我初學(xué)的時(shí)候拿到滿是MOV、ADD、JMP的代碼片段也是同樣的反應(yīng)這玩意兒跟平時(shí)寫的代碼完全不是一個(gè)物種。但后來(lái)真正啃下來(lái)才發(fā)現(xiàn)匯編語(yǔ)言其實(shí)是打開計(jì)算機(jī)底層世界的一把鑰匙。它不是什么過時(shí)的古董而是所有高級(jí)語(yǔ)言的“最終翻譯官”。只要你想搞清楚程序跑起來(lái)的那一刻到底發(fā)生了什么匯編就是繞不開的那一站。這篇內(nèi)容適合兩類人學(xué)過至少一門高級(jí)語(yǔ)言比如C或者Python、想補(bǔ)底層知識(shí)的學(xué)習(xí)者以及工作中排查詭異Bug、做性能分析時(shí)需要讀匯編代碼的開發(fā)者。我會(huì)從“為什么要學(xué)”講到“怎么上手寫”再講到“出問題了怎么調(diào)”每個(gè)環(huán)節(jié)都配上我踩過的坑和值得注意的細(xì)節(jié)。1. 為什么說匯編語(yǔ)言是“高級(jí)語(yǔ)言的翻譯官”1.1 從一段高級(jí)代碼到CPU能執(zhí)行的指令先看一個(gè)最簡(jiǎn)單的C語(yǔ)言表達(dá)式a b c;。一行代碼程序員看來(lái)清爽得很。但在CPU眼里它什么都不是——CPU只認(rèn)二進(jìn)制的機(jī)器指令不認(rèn)C、更不認(rèn)Java和Python。編譯器的工作就是把這行代碼翻譯成一串CPU能識(shí)別的指令。在x86架構(gòu)上翻譯結(jié)果大致是這樣的MOV EAX, [b] ; 把變量b的值從內(nèi)存取到EAX寄存器 ADD EAX, [c] ; 把變量c的值加到EAX上 MOV [a], EAX ; 把結(jié)果存回變量a的內(nèi)存位置這就是匯編語(yǔ)言的本質(zhì)機(jī)器指令的“助記符版本”。機(jī)器指令是0101的二進(jìn)制串人類根本沒法讀匯編語(yǔ)言給每條指令起了個(gè)接近英文的名字比MOV代表move傳送、ADD代表加法、JMP代表jump跳轉(zhuǎn)。它跟機(jī)器指令幾乎一一對(duì)應(yīng)中間沒有任何“隱藏魔法”。我習(xí)慣用一個(gè)生活化類比高級(jí)語(yǔ)言是“外賣軟件”你下單一盤宮保雞丁它不會(huì)告訴你后廚怎么操作匯編語(yǔ)言則是“廚房操作手冊(cè)”每一句都是對(duì)廚師的直接指令——“取雞肉”“倒油”“大火翻炒”。編譯器就是那個(gè)把外賣需求翻譯成廚房操作流程的中間人。翻譯得好的編譯器做出來(lái)的菜又好吃又省燃?xì)夥g得差的又慢又費(fèi)材料。很多人第一個(gè)疑問是既然編譯器這么厲害我還要學(xué)匯編干嘛答案是在絕大多數(shù)場(chǎng)景你確實(shí)不需要親手寫匯編但如果你想回答下面任何一個(gè)問題匯編都是繞不開的——程序?yàn)槭裁纯D、內(nèi)存為什么被越界改寫、某個(gè)函數(shù)為什么沒按預(yù)期運(yùn)行。這些問題追到源碼層面往往沒有答案只有往下看匯編才能看見真實(shí)發(fā)生的事。1.2 現(xiàn)在還有必要學(xué)匯編嗎我遇到過不少開發(fā)者覺得匯編是上世紀(jì)的東西。這種想法可以理解但它忽略了三個(gè)現(xiàn)實(shí)場(chǎng)景第一個(gè)是性能關(guān)鍵路徑。某些熱點(diǎn)代碼經(jīng)過多種編譯優(yōu)化之后依然不夠快這時(shí)候需要人工檢查編譯器生成的指令甚至手寫替換。尤其是SIMD這類加速指令手工編排能榨出明顯性能收益。我見過有人僅僅是把一段向量運(yùn)算的循環(huán)改成匯編指令運(yùn)行時(shí)間就縮短了幾十倍這不是夸張。第二個(gè)是底層開發(fā)和逆向分析。寫B(tài)ootloader、操作系統(tǒng)內(nèi)核的啟動(dòng)代碼、嵌入式裸機(jī)程序短期內(nèi)根本繞不開匯編。安全領(lǐng)域的漏洞分析更是如此緩沖區(qū)溢出、ROP鏈構(gòu)造原理全部落在匯編層面。不讀匯編逆向工程就無(wú)從談起。第三個(gè)是提升排查問題的直覺。哪怕你只學(xué)會(huì)了“看”匯編調(diào)試器里每次單步跟蹤都能讀懂排查內(nèi)存越界、指針錯(cuò)誤、整數(shù)溢出這類問題就會(huì)快很多。高級(jí)語(yǔ)言把細(xì)節(jié)隱藏得太好了一出問題就像隔著一層霧匯編能把霧吹散。1.3 匯編語(yǔ)言的“方言”與架構(gòu)選擇匯編語(yǔ)言不是一套而是跟著CPU架構(gòu)走。最常見的兩大派系是x86和ARM。同一個(gè)“把寄存器清零”的動(dòng)作x86上可能是XOR EAX, EAXARM上可能就是MOV R0, #0指令集不同語(yǔ)法也不同。即便都在x86上前端匯編器還有兩套語(yǔ)法風(fēng)格Intel語(yǔ)法和ATT語(yǔ)法。Intel語(yǔ)法是“目標(biāo)在前源在后”比如MOV EAX, 1ATT語(yǔ)法的操作數(shù)順序反過來(lái)還要在寄存器前加個(gè)百分號(hào)比如movl $1, %eax。初學(xué)者如果兩份資料混著看很容易被繞暈。我的建議是入門階段選x86加Intel語(yǔ)法原因是資料最多、工具鏈最成熟、報(bào)錯(cuò)信息最容易查。ARM等有了基礎(chǔ)之后再接觸很多概念是相通的切換成本并不高。先在一個(gè)方向上建立完整的底層模型比同時(shí)混著多個(gè)架構(gòu)要高效得多。2. 從頭拆解的核心概念寄存器、指令、尋址與內(nèi)存這一章相當(dāng)于一份速查手冊(cè)我按照自己當(dāng)年學(xué)習(xí)的路徑來(lái)組織從最基礎(chǔ)的寄存器講到最容易勸退的尋址模式。其中穿插的每個(gè)“坑”都是我或身邊同學(xué)真實(shí)踩過的。2.1 寄存器CPU內(nèi)部的高速“草稿紙”寄存器是理解匯編語(yǔ)言的第一塊基石。CPU里能存儲(chǔ)數(shù)據(jù)的地方非常有限但速度極快可以把它們想象成CPU內(nèi)部的臨時(shí)草稿紙。以x86的32位模式為例主要寄存器及典型用途如下寄存器典型用途EAX累加器很多算術(shù)指令的默認(rèn)操作數(shù)函數(shù)返回值常放在這里EBX基址寄存器常用來(lái)保存內(nèi)存地址ECX計(jì)數(shù)器循環(huán)類指令的默認(rèn)計(jì)數(shù)器EDX數(shù)據(jù)寄存器配合EAX存放64位乘法結(jié)果或除法余數(shù)ESI / EDI源/目的變址寄存器常與字符串操作指令搭配EBP基址指針指向當(dāng)前棧幀底部ESP棧指針始終指向棧頂這些寄存器都是32位寬但還有一部分是可以“拆開用”的。EAX的低16位叫AXAX又可分為高8位AH和低8位AL。這種特性給不熟悉的人留下了不少陷阱。舉一個(gè)我印象極深的例子EAX寄存器里存著FFFF0000這時(shí)執(zhí)行一條MOV AX, 1234很多新手以為會(huì)清空整個(gè)EAX但實(shí)際上EAX的高16位保持不變、低16位被覆蓋成1234最終結(jié)果是FFFF1234。這看起來(lái)像是一種“部分賦值”卻特別容易在一些拼接數(shù)據(jù)的代碼里引發(fā)詭異Bug。知道寄存器還能拆分使用排查問題時(shí)就多了個(gè)心眼。2.2 指令集CPU能聽懂的命令指令集是匯編語(yǔ)言的核心詞匯表。我沒有按手冊(cè)一條條背而是按功能分類記憶進(jìn)度快很多功能分類常見指令示例說明數(shù)據(jù)傳送MOV、PUSH、POP、LEA在寄存器、內(nèi)存、棧之間搬數(shù)據(jù)算術(shù)運(yùn)算ADD、SUB、MUL、DIV、INC、DEC加、減、乘、除、自增、自減邏輯運(yùn)算AND、OR、XOR、NOT位運(yùn)算常用XOR來(lái)快速清零比較跳轉(zhuǎn)CMP、JMP、JE、JNE、JGE比較后根據(jù)結(jié)果跳轉(zhuǎn)函數(shù)調(diào)用CALL、RET調(diào)用函數(shù)和返回字符串操作MOVS、CMPS、STOS批量搬運(yùn)或比較內(nèi)存數(shù)據(jù)理解CMP和條件跳轉(zhuǎn)是初學(xué)必經(jīng)的一個(gè)坎。CMP不是“執(zhí)行比較然后給出結(jié)果”它的本質(zhì)是做一個(gè)減法運(yùn)算但減法結(jié)果不保存只更新標(biāo)志寄存器里的標(biāo)志位。比如CMP EAX, EBX會(huì)計(jì)算EAX減EBX如果兩者相等結(jié)果為零ZF零標(biāo)志位被置為1。緊接著的JE .done就是看ZFZF為1就跳轉(zhuǎn)。所以CMP和JE是典型的“前后搭配”一條負(fù)責(zé)評(píng)估條件一條負(fù)責(zé)根據(jù)條件決定去向。標(biāo)志位還包括進(jìn)位標(biāo)志CF、符號(hào)標(biāo)志SF、溢出標(biāo)志OF等。處理多字節(jié)加法、判斷大小關(guān)系時(shí)都會(huì)用到。這條鏈路搞明白了就理解了很多分支語(yǔ)句在底層的運(yùn)作方式。高級(jí)語(yǔ)言里的if、switch編譯后大量表現(xiàn)為CMP加各種Jcc條件跳轉(zhuǎn)指令。2.3 尋址方式定位數(shù)據(jù)的幾條路尋址方式聽上去像術(shù)語(yǔ)其實(shí)問的就是一句話這一條指令要操作的數(shù)據(jù)去哪兒找最直接的是立即數(shù)尋址MOV EAX, 1數(shù)字直接寫在指令里就像告訴你“把1放進(jìn)EAX”。然后是寄存器尋址MOV EAX, EBX從另一個(gè)寄存器把值復(fù)制過來(lái)。接下來(lái)是內(nèi)存相關(guān)尋址MOV EAX, [0x1234]去內(nèi)存0x1234這個(gè)地址取數(shù)據(jù)MOV EAX, [EBX]EBX寄存器里存的是地址照著地址去取再?gòu)?fù)雜一點(diǎn)是MOV EAX, [EBP 4]地址等于EBP的值再加偏移量4。為什么匯編要搞出這么多尋址方式因?yàn)樗鼈冊(cè)诟呒?jí)語(yǔ)言里對(duì)應(yīng)著指針、數(shù)組、結(jié)構(gòu)體這些日常概念。比如數(shù)組遍歷編譯器可以用一條MOV EAX, [EBX ECX*4]完成“基地址 索引 * 元素大小”的計(jì)算這是高級(jí)語(yǔ)言一個(gè)arr[i]在底層的典型展開。理解了尋址方式你才能真正看懂編譯器生成的代碼也才知道為什么有些代碼即使沒寫錯(cuò)也慢——可能就是多了一條不必要的內(nèi)存訪問。初學(xué)最容易忽略的細(xì)節(jié)是操作數(shù)大小。[EBX]到底取一個(gè)字節(jié)、一個(gè)字還是一個(gè)雙字取決于指令里有沒有明確說明。MOV AL, [EBX]取一個(gè)字節(jié)MOV AX, [EBX]取兩個(gè)字節(jié)。如果寫成MOV EAX, [EBX]匯編器默認(rèn)取四個(gè)字節(jié)。稍不留意讀多讀少都會(huì)導(dǎo)致結(jié)果完全錯(cuò)誤。2.4 內(nèi)存分段模型代碼、數(shù)據(jù)與棧x86體系把內(nèi)存劃分成不同類型由段寄存器來(lái)指路CS指向代碼段、DS指向數(shù)據(jù)段、SS指向棧段、ES是附加段。寫程序時(shí)指令放進(jìn)代碼段全局變量放數(shù)據(jù)段局部變量和函數(shù)調(diào)用信息放棧段。棧是最有意思的一塊區(qū)域因?yàn)樗皇窍蛏显鲩L(zhǎng)而是從高地址向低地址推進(jìn)。執(zhí)行PUSH EAX時(shí)ESP會(huì)先減4再把數(shù)據(jù)寫到ESP指向的位置POP EAX則相反先從當(dāng)前ESP位置取數(shù)據(jù)再把ESP加4。這個(gè)“向下增長(zhǎng)”的設(shè)定坑過不少人。新手畫圖時(shí)常假設(shè)棧像數(shù)組一樣從低地址往上長(zhǎng)結(jié)果分析緩沖區(qū)溢出時(shí)方向全反。后來(lái)我干脆把棧想象成“往下疊盤子”每壓一個(gè)盤子頂峰位置就往下移一點(diǎn)。理解了方向才能正確解讀棧幀里的地址偏移也為后面的函數(shù)調(diào)用機(jī)制打下基礎(chǔ)。這里還想提醒一句不同架構(gòu)對(duì)棧方向的處理細(xì)節(jié)略有差異但在x86上這幾條規(guī)律足夠應(yīng)對(duì)絕大多數(shù)學(xué)習(xí)場(chǎng)景。3. 第一個(gè)實(shí)用的匯編程序從零寫一個(gè)字符串長(zhǎng)度統(tǒng)計(jì)函數(shù)背語(yǔ)法不如直接動(dòng)手。我建議初學(xué)者的第一個(gè)程序別寫“輸出Hello World”而是寫一個(gè)更有價(jià)值的函數(shù)統(tǒng)計(jì)一個(gè)以0結(jié)尾的字符串長(zhǎng)度。這個(gè)例子涵蓋了內(nèi)存訪問、循環(huán)、條件判斷、函數(shù)調(diào)用麻雀雖小五臟俱全而且可以直接和C語(yǔ)言程序鏈接運(yùn)行。3.1 準(zhǔn)備工作需要哪些工具開發(fā)匯編不需要重型IDE。我慣用的組合是一個(gè)開源匯編器把匯編源碼編譯成目標(biāo)文件、一個(gè)命令行調(diào)試器用來(lái)查看寄存器和內(nèi)存、再加上系統(tǒng)自帶的鏈接器。以類Unix環(huán)境為例匯編器可以用NASM編譯時(shí)指定生成32位目標(biāo)文件。命令大致是nasm -f elf32 str_len.asm -o str_len.o接下來(lái)還需要一個(gè)C語(yǔ)言測(cè)試程序用一個(gè)main函數(shù)去調(diào)用匯編函數(shù)。為什么不直接寫完整的匯編程序因?yàn)橥暾膮R編程序還涉及程序入口、程序頭等一大堆信息對(duì)初學(xué)者來(lái)說信息量太大。先寫一個(gè)函數(shù)由C語(yǔ)言的main調(diào)用既貼近真實(shí)開發(fā)場(chǎng)景又能顯著降低門檻。3.2 一段可以直接抄走的代碼; 函數(shù)功能統(tǒng)計(jì)以0結(jié)尾的字符串長(zhǎng)度 ; 調(diào)用約定cdecl ; 入口參數(shù)字符串起始地址通過棧傳遞 ; 返回值EAX 字符串長(zhǎng)度 SECTION .text GLOBAL str_len str_len: push ebp ; 保存上一個(gè)函數(shù)的?；?mov ebp, esp ; 建立當(dāng)前函數(shù)的棧幀 mov ebx, [ebp 8] ; 第一個(gè)參數(shù)字符串地址 xor eax, eax ; 計(jì)數(shù)器清零 .loop: cmp byte [ebx], 0 ; 檢查當(dāng)前字符是否為0 je .done ; 是0說明字符串結(jié)束 inc ebx ; 指針后移一個(gè)字節(jié) inc eax ; 長(zhǎng)度加1 jmp .loop ; 繼續(xù)循環(huán) .done: pop ebp ; 恢復(fù)上一個(gè)函數(shù)的?；?ret ; 返回EAX就是長(zhǎng)度對(duì)應(yīng)的C語(yǔ)言測(cè)試程序#include stdio.h extern int str_len(char *s); int main(void) { char *msg hello; int len str_len(msg); printf(len %d\n, len); return 0; }編譯鏈接運(yùn)行nasm -f elf32 str_len.asm -o str_len.o gcc -m32 main.c str_len.o -o test ./test輸出應(yīng)該是len 5。如果報(bào)錯(cuò)找不到頭文件或鏈接庫(kù)通常是因?yàn)?4位系統(tǒng)缺少32位編譯環(huán)境需要安裝對(duì)應(yīng)的32位兼容庫(kù)。3.3 逐行解讀為什么這么寫函數(shù)開頭三行值得認(rèn)真看push ebp、mov ebp, esp、mov ebx, [ebp 8]。這里涉及的就是“棧幀”的概念。CALL str_len執(zhí)行時(shí)CPU會(huì)把返回地址壓棧然后跳轉(zhuǎn)到函數(shù)入口進(jìn)入函數(shù)后push ebp保存調(diào)用者的棧基址mov ebp, esp把當(dāng)前棧頂設(shè)為新函數(shù)的棧底。接著訪問[ebp 8]就能拿到第一個(gè)參數(shù)。為什么偏移是8而不是4因?yàn)閺腅BP往上數(shù)先是本函數(shù)壓入的舊EBP4字節(jié)再是CALL壓入的返回地址4字節(jié)這兩項(xiàng)各占4字節(jié)所以第一個(gè)參數(shù)在偏移8的位置。這個(gè)計(jì)算邏輯一旦想清楚后面涉及多參數(shù)、局部變量的函數(shù)就不會(huì)暈。xor eax, eax這條指令是把EAX清零的慣用寫法。任何數(shù)與自身異或都會(huì)得到0所以這條指令等價(jià)于mov eax, 0但編碼更短對(duì)流水線也更友好。后來(lái)我看編譯器生成的代碼發(fā)現(xiàn)它同樣偏愛這種寫法這是最典型的“用數(shù)學(xué)性質(zhì)優(yōu)化代碼”的例子。cmp byte [ebx], 0這里的byte關(guān)鍵字很容易被漏寫。如果不寫B(tài)YTE匯編器根本不知道是拿一個(gè)字節(jié)、一個(gè)字還是雙字去跟0比較要么報(bào)錯(cuò)要么生成完全不符合預(yù)期的指令。這是初學(xué)匯編最常踩的坑之一。另外因?yàn)樽址厥且粋€(gè)字節(jié)所以指針inc ebx只移動(dòng)一個(gè)字節(jié)如果遍歷的是一個(gè)32位整數(shù)數(shù)組這里就得改成add ebx, 4。3.4 編譯鏈接中的幾個(gè)實(shí)際問題我自己第一次編譯時(shí)在64位Linux上直接gcc main.c str_len.o結(jié)果報(bào)了無(wú)數(shù)頭文件錯(cuò)誤原因就是默認(rèn)按64位鏈接而我的匯編目標(biāo)是32位。加上-m32之后又提示缺少32位運(yùn)行庫(kù)。裝好庫(kù)后才順利跑通。另外這個(gè)函數(shù)遵循的是cdecl調(diào)用約定參數(shù)從右往左壓棧由調(diào)用方清理?xiàng)！Ｎ以趨R編里沒有額外清理?xiàng)Ｒ驗(yàn)榍謇韯?dòng)作發(fā)生在C函數(shù)里如果用了stdcall約定按規(guī)則清棧的就是被調(diào)用方。這些約定細(xì)節(jié)下一章還會(huì)展開。如果運(yùn)行結(jié)果不是預(yù)期先別急著懷疑業(yè)務(wù)邏輯用調(diào)試器單步走一遍看EBX指向的地址內(nèi)容是否真是字符串、計(jì)數(shù)每次是否加1。調(diào)試器是匯編學(xué)習(xí)里最好的老師這一點(diǎn)無(wú)論怎么強(qiáng)調(diào)都不過分。4. 高級(jí)語(yǔ)言與匯編的對(duì)應(yīng)關(guān)系編譯器到底干了什么掌握了基本語(yǔ)法后下一步是建立“高級(jí)代碼 → 匯編”的映射直覺。這一章是我認(rèn)為學(xué)習(xí)性價(jià)比最高的部分因?yàn)樗茏屇銖摹皶?huì)寫匯編”進(jìn)階到“能讀懂編譯器”。4.1 函數(shù)調(diào)用時(shí)的棧幀機(jī)制上一章的str_len函數(shù)已經(jīng)展示了棧幀的雛形。完整來(lái)看一次函數(shù)調(diào)用的流程是這樣的調(diào)用方先把參數(shù)壓棧然后執(zhí)行CALLCALL會(huì)把返回地址壓棧并跳轉(zhuǎn)到函數(shù)入口被調(diào)用方繼續(xù)壓入舊的EBP把ESP復(fù)制到EBP建立自己的棧幀函數(shù)執(zhí)行完依次恢復(fù)EBP、執(zhí)行RET跳回返回地址最后調(diào)用方清理參數(shù)區(qū)。這套流程幾乎適用于所有主流語(yǔ)言編譯出的代碼。理解了它你就能解釋很多詭異現(xiàn)象為什么局部變量在函數(shù)返回后不能繼續(xù)使用因?yàn)槟菈K棧內(nèi)存已經(jīng)“釋放”了為什么棧溢出攻擊喜歡覆蓋返回地址因?yàn)榉祷氐刂肪痛嬖跅墓潭ㄎ恢?。在調(diào)試器里觀察棧幀時(shí)我建議重點(diǎn)關(guān)注EBP和ESP之間的關(guān)系。ESP隨時(shí)可能變化一旦壓棧出棧就會(huì)移動(dòng)EBP在函數(shù)生命周期內(nèi)基本不動(dòng)所以編譯器習(xí)慣以EBP為基準(zhǔn)去訪問參數(shù)和局部變量。這個(gè)視角能快速定位“為什么參數(shù)取出來(lái)的值不對(duì)”這類問題。4.2 調(diào)用約定跨語(yǔ)言協(xié)作的“合約”在匯編函數(shù)和C函數(shù)之間互調(diào)全靠調(diào)用約定維持秩序。我整理了三張最常見的“合約”約定名稱參數(shù)傳遞方式清棧責(zé)任cdecl參數(shù)從右往左壓棧調(diào)用方負(fù)責(zé)stdcall參數(shù)從右往左壓棧被調(diào)用方負(fù)責(zé)fastcall前兩個(gè)參數(shù)走寄存器其余壓棧視具體實(shí)現(xiàn)而定寫內(nèi)聯(lián)匯編或者匯編文件與C混合編譯時(shí)調(diào)用約定不匹配是崩潰的常見原因。我遇到過一次程序運(yùn)行正常但偶爾返回詭異值的Bug最后發(fā)現(xiàn)是匯編函數(shù)用了stdcall清理?xiàng)６鳦那邊按照cdecl再次清理兩條清理邏輯疊加把棧徹底搞亂了。從那以后我在每個(gè)匯編函數(shù)開頭都會(huì)用注釋寫明調(diào)用約定避免自己忘記。4.3 觀察編譯器優(yōu)化反匯編是最好的老師安裝了調(diào)試器之后建議做一個(gè)很直觀的小實(shí)驗(yàn)寫一個(gè)簡(jiǎn)單的C函數(shù)然后查看它對(duì)應(yīng)的匯編代碼。編譯器在優(yōu)化時(shí)做的一些事情往往比教科書里的示例更精彩。比如求一個(gè)數(shù)乘以10編譯器可能不會(huì)生成乘法指令而是生成(x 3) (x 1)因?yàn)橐莆缓图臃ū瘸朔ǜ?。再比如?shù)組下標(biāo)訪問編譯器會(huì)精心計(jì)算偏移盡量用一條尋址指令完成。這些優(yōu)化策略只有親眼看到匯編才體會(huì)得到。排查性能瓶頸時(shí)編譯器通常提供“輸出匯編文件”的選項(xiàng)。遇到熱點(diǎn)代碼性能不達(dá)標(biāo)看一眼它的匯編很多時(shí)候比盲猜快得多?？赡芸雌饋?lái)只是多了一條無(wú)謂的內(nèi)存讀或者某個(gè)循環(huán)沒被展開優(yōu)化方向立刻就清楚了。4.4 內(nèi)聯(lián)匯編是“手術(shù)刀”不是“菜刀”C語(yǔ)言等高級(jí)語(yǔ)言允許在代碼里直接嵌入?yún)R編片段這就是內(nèi)聯(lián)匯編。寫一個(gè)最簡(jiǎn)單例子int add_one(int x) { __asm__(addl $1, %0 : r(x)); return x; }這段代碼的意思是用一條addl指令把x加上1。功能上等價(jià)于x但如果你以為這樣就更“底層”、更快那就錯(cuò)了。我有一次在某段代碼里用手寫匯編“優(yōu)化”了一個(gè)局部變量的遞增結(jié)果這段匯編破壞了編譯器對(duì)寄存器的分配規(guī)則導(dǎo)致后續(xù)代碼的優(yōu)化全部失效整體性能反而下降。之后我就給自己立了一條規(guī)矩內(nèi)聯(lián)匯編是最后手段必須先用量化工具確認(rèn)瓶頸確實(shí)在這里再考慮動(dòng)它否則99%的情況讓編譯器自己優(yōu)化才是正途。5. 初學(xué)匯編的常見問題排查實(shí)錄這一章是實(shí)戰(zhàn)部分的整理。我特意把問題和排查思路按場(chǎng)景歸類方便你日后當(dāng)速查表用。5.1 一運(yùn)行就段錯(cuò)誤Segmentation Fault段錯(cuò)誤是匯編初學(xué)者遇到最多的崩潰形式。它的本質(zhì)是程序訪問了非法內(nèi)存地址。排查順序我建議這樣先檢查所有內(nèi)存訪問指令[...]里的寄存器值確認(rèn)地址是否合理再檢查字符串是否真的以0結(jié)尾如果遍歷了一個(gè)沒有終止符的數(shù)組很容易一路讀下去訪問到不可讀的地址最后檢查PUSH和POP是否配對(duì)棧不平衡會(huì)讓RET跳到錯(cuò)誤的地方。我自己曾寫出過“只PUSH不POP”的函數(shù)調(diào)用第二次時(shí)棧里累積了越來(lái)越多的垃圾數(shù)據(jù)程序表現(xiàn)是第一次調(diào)用正常、第二次隨機(jī)崩潰排查了很久才發(fā)現(xiàn)是棧清理缺失。5.2 循環(huán)只跑一次或者干脆變成死循環(huán)這類問題十有八九和寄存器沖突有關(guān)。ECX常被用作循環(huán)計(jì)數(shù)器但如果循環(huán)體內(nèi)調(diào)用了另一個(gè)函數(shù)那個(gè)函數(shù)也把ECX當(dāng)成臨時(shí)寄存器用了計(jì)數(shù)就被覆蓋。解決思路是約定好哪些寄存器在函數(shù)調(diào)用后不變嚴(yán)格遵守。這里就有必要記住caller-saved和callee-saved的概念。簡(jiǎn)單說某些寄存器的值在函數(shù)調(diào)用后很可能被改掉所以調(diào)用方要在調(diào)用前保護(hù)另一些寄存器由被調(diào)用方保護(hù)調(diào)用方可以放心使用。在匯編函數(shù)里如果需要保護(hù)某個(gè)寄存器就在函數(shù)開頭PUSH結(jié)尾POP形成完整的進(jìn)出平衡。5.3 數(shù)據(jù)定義寬度不對(duì)用匯編定義數(shù)據(jù)時(shí)dbdefine byte表示一個(gè)字節(jié)dw表示一個(gè)字2字節(jié)dd表示一個(gè)雙字4字節(jié)。很多人第一次寫字符串定義時(shí)用了dd導(dǎo)致每個(gè)字符被放成4字節(jié)整個(gè)內(nèi)存布局完全錯(cuò)亂遍歷結(jié)果自然一塌糊涂。正確寫法是字符串用db逐一存放msg: db hello, 0這里末尾的0就是字符串終止符。只要把數(shù)據(jù)寬度定義和內(nèi)存訪問寬度對(duì)齊很多“字符串讀取結(jié)果怪異”的問題都能避免。5.4 調(diào)試器的三板斧匯編開發(fā)中調(diào)試器比任何打印日志都靠譜。核心動(dòng)作其實(shí)就三個(gè)設(shè)置斷點(diǎn)在某條指令處暫停查看所有寄存器的當(dāng)前值按指定格式查看某塊內(nèi)存的內(nèi)容。遇到“我到底改沒改這個(gè)變量”這類問題在調(diào)試器里直接看內(nèi)存比在源碼里猜測(cè)快得多。寄存器里存儲(chǔ)的地址是多少、那片內(nèi)存的數(shù)據(jù)是什么一眼就能確認(rèn)。調(diào)試匯編沒有高級(jí)語(yǔ)言那么多隱藏邏輯一切都很“物理”步步可見。5.5 一條救命經(jīng)驗(yàn)先寫小函數(shù)再拼大系統(tǒng)新手特別容易一上來(lái)就寫幾百行匯編然后編譯報(bào)錯(cuò)卻不知道從何查起。我后來(lái)養(yǎng)成的習(xí)慣是每個(gè)函數(shù)單獨(dú)寫成獨(dú)立模塊配一個(gè)C語(yǔ)言的測(cè)試殼把輸入輸出打印出來(lái)確認(rèn)函數(shù)行為正確之后再組裝進(jìn)整個(gè)工程。匯編的調(diào)試成本遠(yuǎn)高于高級(jí)語(yǔ)言把驗(yàn)證粒度切得越小定位問題越容易。一次只驗(yàn)證一個(gè)函數(shù)的輸入輸出出錯(cuò)了范圍也小。那些在幾百行匯編里翻找“某條指令操作數(shù)寫反”的體驗(yàn)經(jīng)歷過一次就不會(huì)想再來(lái)一次。最后再分享一點(diǎn)個(gè)人體會(huì)我對(duì)匯編的態(tài)度一直很微妙日常工作里幾乎寫不到它但它給我建立的底層直覺幾乎每天都在發(fā)揮作用。排查內(nèi)存問題、理解性能計(jì)數(shù)器、閱讀崩潰日志里那幾行寄存器快照靠的都是當(dāng)年啃匯編時(shí)建立的模型。如果讓我給剛學(xué)匯編的人三個(gè)建議我會(huì)說第一寄存器就是一切的基礎(chǔ)先把它玩熟不要急著背所有指令第二每學(xué)一個(gè)指令就寫一個(gè)5到10行的迷你函數(shù)親眼看看運(yùn)行結(jié)果不要讓概念停留在紙面上第三遇到看不懂的代碼別硬背打開調(diào)試器跟著寄存器一步一步走比反復(fù)閱讀手冊(cè)有效得多。還有一個(gè)壓縮學(xué)習(xí)曲線的小技巧常用指令其實(shí)只有二三十條把高頻指令練到條件反射冷門指令用到時(shí)再查手冊(cè)就夠了。真正的能力不是背下所有指令而是知道一個(gè)功能大概需要哪些指令、能不能優(yōu)化、能優(yōu)化到什么程度。這個(gè)手感只有親手寫過匯編的人才會(huì)有。 匯編語(yǔ)言入門：從寄存器、指令集到編譯器底層實(shí)現(xiàn)
學(xué)編程這些年我見過太多人一聽到“匯編語(yǔ)言”這四個(gè)字就頭皮發(fā)麻。在很多教材和課程里它往往被安排到第二章——講完基本概念之后第一道需要真正面向底層的大門。說實(shí)話我初學(xué)的時(shí)候拿到滿是MOV、ADD、JMP的代碼片段也是同樣的反應(yīng)這玩意兒跟平時(shí)寫的代碼完全不是一個(gè)物種。但后來(lái)真正啃下來(lái)才發(fā)現(xiàn)匯編語(yǔ)言其實(shí)是打開計(jì)算機(jī)底層世界的一把鑰匙。它不是什么過時(shí)的古董而是所有高級(jí)語(yǔ)言的“最終翻譯官”。只要你想搞清楚程序跑起來(lái)的那一刻到底發(fā)生了什么匯編就是繞不開的那一站。這篇內(nèi)容適合兩類人學(xué)過至少一門高級(jí)語(yǔ)言比如C或者Python、想補(bǔ)底層知識(shí)的學(xué)習(xí)者以及工作中排查詭異Bug、做性能分析時(shí)需要讀匯編代碼的開發(fā)者。我會(huì)從“為什么要學(xué)”講到“怎么上手寫”再講到“出問題了怎么調(diào)”每個(gè)環(huán)節(jié)都配上我踩過的坑和值得注意的細(xì)節(jié)。1. 為什么說匯編語(yǔ)言是“高級(jí)語(yǔ)言的翻譯官”1.1 從一段高級(jí)代碼到CPU能執(zhí)行的指令先看一個(gè)最簡(jiǎn)單的C語(yǔ)言表達(dá)式a b c;。一行代碼程序員看來(lái)清爽得很。但在CPU眼里它什么都不是——CPU只認(rèn)二進(jìn)制的機(jī)器指令不認(rèn)C、更不認(rèn)Java和Python。編譯器的工作就是把這行代碼翻譯成一串CPU能識(shí)別的指令。在x86架構(gòu)上翻譯結(jié)果大致是這樣的MOV EAX, [b] ; 把變量b的值從內(nèi)存取到EAX寄存器 ADD EAX, [c] ; 把變量c的值加到EAX上 MOV [a], EAX ; 把結(jié)果存回變量a的內(nèi)存位置這就是匯編語(yǔ)言的本質(zhì)機(jī)器指令的“助記符版本”。機(jī)器指令是0101的二進(jìn)制串人類根本沒法讀匯編語(yǔ)言給每條指令起了個(gè)接近英文的名字比MOV代表move傳送、ADD代表加法、JMP代表jump跳轉(zhuǎn)。它跟機(jī)器指令幾乎一一對(duì)應(yīng)中間沒有任何“隱藏魔法”。我習(xí)慣用一個(gè)生活化類比高級(jí)語(yǔ)言是“外賣軟件”你下單一盤宮保雞丁它不會(huì)告訴你后廚怎么操作匯編語(yǔ)言則是“廚房操作手冊(cè)”每一句都是對(duì)廚師的直接指令——“取雞肉”“倒油”“大火翻炒”。編譯器就是那個(gè)把外賣需求翻譯成廚房操作流程的中間人。翻譯得好的編譯器做出來(lái)的菜又好吃又省燃?xì)夥g得差的又慢又費(fèi)材料。很多人第一個(gè)疑問是既然編譯器這么厲害我還要學(xué)匯編干嘛答案是在絕大多數(shù)場(chǎng)景你確實(shí)不需要親手寫匯編但如果你想回答下面任何一個(gè)問題匯編都是繞不開的——程序?yàn)槭裁纯D、內(nèi)存為什么被越界改寫、某個(gè)函數(shù)為什么沒按預(yù)期運(yùn)行。這些問題追到源碼層面往往沒有答案只有往下看匯編才能看見真實(shí)發(fā)生的事。1.2 現(xiàn)在還有必要學(xué)匯編嗎我遇到過不少開發(fā)者覺得匯編是上世紀(jì)的東西。這種想法可以理解但它忽略了三個(gè)現(xiàn)實(shí)場(chǎng)景第一個(gè)是性能關(guān)鍵路徑。某些熱點(diǎn)代碼經(jīng)過多種編譯優(yōu)化之后依然不夠快這時(shí)候需要人工檢查編譯器生成的指令甚至手寫替換。尤其是SIMD這類加速指令手工編排能榨出明顯性能收益。我見過有人僅僅是把一段向量運(yùn)算的循環(huán)改成匯編指令運(yùn)行時(shí)間就縮短了幾十倍這不是夸張。第二個(gè)是底層開發(fā)和逆向分析。寫B(tài)ootloader、操作系統(tǒng)內(nèi)核的啟動(dòng)代碼、嵌入式裸機(jī)程序短期內(nèi)根本繞不開匯編。安全領(lǐng)域的漏洞分析更是如此緩沖區(qū)溢出、ROP鏈構(gòu)造原理全部落在匯編層面。不讀匯編逆向工程就無(wú)從談起。第三個(gè)是提升排查問題的直覺。哪怕你只學(xué)會(huì)了“看”匯編調(diào)試器里每次單步跟蹤都能讀懂排查內(nèi)存越界、指針錯(cuò)誤、整數(shù)溢出這類問題就會(huì)快很多。高級(jí)語(yǔ)言把細(xì)節(jié)隱藏得太好了一出問題就像隔著一層霧匯編能把霧吹散。1.3 匯編語(yǔ)言的“方言”與架構(gòu)選擇匯編語(yǔ)言不是一套而是跟著CPU架構(gòu)走。最常見的兩大派系是x86和ARM。同一個(gè)“把寄存器清零”的動(dòng)作x86上可能是XOR EAX, EAXARM上可能就是MOV R0, #0指令集不同語(yǔ)法也不同。即便都在x86上前端匯編器還有兩套語(yǔ)法風(fēng)格Intel語(yǔ)法和ATT語(yǔ)法。Intel語(yǔ)法是“目標(biāo)在前源在后”比如MOV EAX, 1ATT語(yǔ)法的操作數(shù)順序反過來(lái)還要在寄存器前加個(gè)百分號(hào)比如movl $1, %eax。初學(xué)者如果兩份資料混著看很容易被繞暈。我的建議是入門階段選x86加Intel語(yǔ)法原因是資料最多、工具鏈最成熟、報(bào)錯(cuò)信息最容易查。ARM等有了基礎(chǔ)之后再接觸很多概念是相通的切換成本并不高。先在一個(gè)方向上建立完整的底層模型比同時(shí)混著多個(gè)架構(gòu)要高效得多。2. 從頭拆解的核心概念寄存器、指令、尋址與內(nèi)存這一章相當(dāng)于一份速查手冊(cè)我按照自己當(dāng)年學(xué)習(xí)的路徑來(lái)組織從最基礎(chǔ)的寄存器講到最容易勸退的尋址模式。其中穿插的每個(gè)“坑”都是我或身邊同學(xué)真實(shí)踩過的。2.1 寄存器CPU內(nèi)部的高速“草稿紙”寄存器是理解匯編語(yǔ)言的第一塊基石。CPU里能存儲(chǔ)數(shù)據(jù)的地方非常有限但速度極快可以把它們想象成CPU內(nèi)部的臨時(shí)草稿紙。以x86的32位模式為例主要寄存器及典型用途如下寄存器典型用途EAX累加器很多算術(shù)指令的默認(rèn)操作數(shù)函數(shù)返回值常放在這里EBX基址寄存器常用來(lái)保存內(nèi)存地址ECX計(jì)數(shù)器循環(huán)類指令的默認(rèn)計(jì)數(shù)器EDX數(shù)據(jù)寄存器配合EAX存放64位乘法結(jié)果或除法余數(shù)ESI / EDI源/目的變址寄存器常與字符串操作指令搭配EBP基址指針指向當(dāng)前棧幀底部ESP棧指針始終指向棧頂這些寄存器都是32位寬但還有一部分是可以“拆開用”的。EAX的低16位叫AXAX又可分為高8位AH和低8位AL。這種特性給不熟悉的人留下了不少陷阱。舉一個(gè)我印象極深的例子EAX寄存器里存著FFFF0000這時(shí)執(zhí)行一條MOV AX, 1234很多新手以為會(huì)清空整個(gè)EAX但實(shí)際上EAX的高16位保持不變、低16位被覆蓋成1234最終結(jié)果是FFFF1234。這看起來(lái)像是一種“部分賦值”卻特別容易在一些拼接數(shù)據(jù)的代碼里引發(fā)詭異Bug。知道寄存器還能拆分使用排查問題時(shí)就多了個(gè)心眼。2.2 指令集CPU能聽懂的命令指令集是匯編語(yǔ)言的核心詞匯表。我沒有按手冊(cè)一條條背而是按功能分類記憶進(jìn)度快很多功能分類常見指令示例說明數(shù)據(jù)傳送MOV、PUSH、POP、LEA在寄存器、內(nèi)存、棧之間搬數(shù)據(jù)算術(shù)運(yùn)算ADD、SUB、MUL、DIV、INC、DEC加、減、乘、除、自增、自減邏輯運(yùn)算AND、OR、XOR、NOT位運(yùn)算常用XOR來(lái)快速清零比較跳轉(zhuǎn)CMP、JMP、JE、JNE、JGE比較后根據(jù)結(jié)果跳轉(zhuǎn)函數(shù)調(diào)用CALL、RET調(diào)用函數(shù)和返回字符串操作MOVS、CMPS、STOS批量搬運(yùn)或比較內(nèi)存數(shù)據(jù)理解CMP和條件跳轉(zhuǎn)是初學(xué)必經(jīng)的一個(gè)坎。CMP不是“執(zhí)行比較然后給出結(jié)果”它的本質(zhì)是做一個(gè)減法運(yùn)算但減法結(jié)果不保存只更新標(biāo)志寄存器里的標(biāo)志位。比如CMP EAX, EBX會(huì)計(jì)算EAX減EBX如果兩者相等結(jié)果為零ZF零標(biāo)志位被置為1。緊接著的JE .done就是看ZFZF為1就跳轉(zhuǎn)。所以CMP和JE是典型的“前后搭配”一條負(fù)責(zé)評(píng)估條件一條負(fù)責(zé)根據(jù)條件決定去向。標(biāo)志位還包括進(jìn)位標(biāo)志CF、符號(hào)標(biāo)志SF、溢出標(biāo)志OF等。處理多字節(jié)加法、判斷大小關(guān)系時(shí)都會(huì)用到。這條鏈路搞明白了就理解了很多分支語(yǔ)句在底層的運(yùn)作方式。高級(jí)語(yǔ)言里的if、switch編譯后大量表現(xiàn)為CMP加各種Jcc條件跳轉(zhuǎn)指令。2.3 尋址方式定位數(shù)據(jù)的幾條路尋址方式聽上去像術(shù)語(yǔ)其實(shí)問的就是一句話這一條指令要操作的數(shù)據(jù)去哪兒找最直接的是立即數(shù)尋址MOV EAX, 1數(shù)字直接寫在指令里就像告訴你“把1放進(jìn)EAX”。然后是寄存器尋址MOV EAX, EBX從另一個(gè)寄存器把值復(fù)制過來(lái)。接下來(lái)是內(nèi)存相關(guān)尋址MOV EAX, [0x1234]去內(nèi)存0x1234這個(gè)地址取數(shù)據(jù)MOV EAX, [EBX]EBX寄存器里存的是地址照著地址去取再?gòu)?fù)雜一點(diǎn)是MOV EAX, [EBP 4]地址等于EBP的值再加偏移量4。為什么匯編要搞出這么多尋址方式因?yàn)樗鼈冊(cè)诟呒?jí)語(yǔ)言里對(duì)應(yīng)著指針、數(shù)組、結(jié)構(gòu)體這些日常概念。比如數(shù)組遍歷編譯器可以用一條MOV EAX, [EBX ECX*4]完成“基地址 索引 * 元素大小”的計(jì)算這是高級(jí)語(yǔ)言一個(gè)arr[i]在底層的典型展開。理解了尋址方式你才能真正看懂編譯器生成的代碼也才知道為什么有些代碼即使沒寫錯(cuò)也慢——可能就是多了一條不必要的內(nèi)存訪問。初學(xué)最容易忽略的細(xì)節(jié)是操作數(shù)大小。[EBX]到底取一個(gè)字節(jié)、一個(gè)字還是一個(gè)雙字取決于指令里有沒有明確說明。MOV AL, [EBX]取一個(gè)字節(jié)MOV AX, [EBX]取兩個(gè)字節(jié)。如果寫成MOV EAX, [EBX]匯編器默認(rèn)取四個(gè)字節(jié)。稍不留意讀多讀少都會(huì)導(dǎo)致結(jié)果完全錯(cuò)誤。2.4 內(nèi)存分段模型代碼、數(shù)據(jù)與棧x86體系把內(nèi)存劃分成不同類型由段寄存器來(lái)指路CS指向代碼段、DS指向數(shù)據(jù)段、SS指向棧段、ES是附加段。寫程序時(shí)指令放進(jìn)代碼段全局變量放數(shù)據(jù)段局部變量和函數(shù)調(diào)用信息放棧段。棧是最有意思的一塊區(qū)域因?yàn)樗皇窍蛏显鲩L(zhǎng)而是從高地址向低地址推進(jìn)。執(zhí)行PUSH EAX時(shí)ESP會(huì)先減4再把數(shù)據(jù)寫到ESP指向的位置POP EAX則相反先從當(dāng)前ESP位置取數(shù)據(jù)再把ESP加4。這個(gè)“向下增長(zhǎng)”的設(shè)定坑過不少人。新手畫圖時(shí)常假設(shè)棧像數(shù)組一樣從低地址往上長(zhǎng)結(jié)果分析緩沖區(qū)溢出時(shí)方向全反。后來(lái)我干脆把棧想象成“往下疊盤子”每壓一個(gè)盤子頂峰位置就往下移一點(diǎn)。理解了方向才能正確解讀棧幀里的地址偏移也為后面的函數(shù)調(diào)用機(jī)制打下基礎(chǔ)。這里還想提醒一句不同架構(gòu)對(duì)棧方向的處理細(xì)節(jié)略有差異但在x86上這幾條規(guī)律足夠應(yīng)對(duì)絕大多數(shù)學(xué)習(xí)場(chǎng)景。3. 第一個(gè)實(shí)用的匯編程序從零寫一個(gè)字符串長(zhǎng)度統(tǒng)計(jì)函數(shù)背語(yǔ)法不如直接動(dòng)手。我建議初學(xué)者的第一個(gè)程序別寫“輸出Hello World”而是寫一個(gè)更有價(jià)值的函數(shù)統(tǒng)計(jì)一個(gè)以0結(jié)尾的字符串長(zhǎng)度。這個(gè)例子涵蓋了內(nèi)存訪問、循環(huán)、條件判斷、函數(shù)調(diào)用麻雀雖小五臟俱全而且可以直接和C語(yǔ)言程序鏈接運(yùn)行。3.1 準(zhǔn)備工作需要哪些工具開發(fā)匯編不需要重型IDE。我慣用的組合是一個(gè)開源匯編器把匯編源碼編譯成目標(biāo)文件、一個(gè)命令行調(diào)試器用來(lái)查看寄存器和內(nèi)存、再加上系統(tǒng)自帶的鏈接器。以類Unix環(huán)境為例匯編器可以用NASM編譯時(shí)指定生成32位目標(biāo)文件。命令大致是nasm -f elf32 str_len.asm -o str_len.o接下來(lái)還需要一個(gè)C語(yǔ)言測(cè)試程序用一個(gè)main函數(shù)去調(diào)用匯編函數(shù)。為什么不直接寫完整的匯編程序因?yàn)橥暾膮R編程序還涉及程序入口、程序頭等一大堆信息對(duì)初學(xué)者來(lái)說信息量太大。先寫一個(gè)函數(shù)由C語(yǔ)言的main調(diào)用既貼近真實(shí)開發(fā)場(chǎng)景又能顯著降低門檻。3.2 一段可以直接抄走的代碼; 函數(shù)功能統(tǒng)計(jì)以0結(jié)尾的字符串長(zhǎng)度 ; 調(diào)用約定cdecl ; 入口參數(shù)字符串起始地址通過棧傳遞 ; 返回值EAX 字符串長(zhǎng)度 SECTION .text GLOBAL str_len str_len: push ebp ; 保存上一個(gè)函數(shù)的?；?mov ebp, esp ; 建立當(dāng)前函數(shù)的棧幀 mov ebx, [ebp 8] ; 第一個(gè)參數(shù)字符串地址 xor eax, eax ; 計(jì)數(shù)器清零 .loop: cmp byte [ebx], 0 ; 檢查當(dāng)前字符是否為0 je .done ; 是0說明字符串結(jié)束 inc ebx ; 指針后移一個(gè)字節(jié) inc eax ; 長(zhǎng)度加1 jmp .loop ; 繼續(xù)循環(huán) .done: pop ebp ; 恢復(fù)上一個(gè)函數(shù)的?；?ret ; 返回EAX就是長(zhǎng)度對(duì)應(yīng)的C語(yǔ)言測(cè)試程序#include stdio.h extern int str_len(char *s); int main(void) { char *msg hello; int len str_len(msg); printf(len %d\n, len); return 0; }編譯鏈接運(yùn)行nasm -f elf32 str_len.asm -o str_len.o gcc -m32 main.c str_len.o -o test ./test輸出應(yīng)該是len 5。如果報(bào)錯(cuò)找不到頭文件或鏈接庫(kù)通常是因?yàn)?4位系統(tǒng)缺少32位編譯環(huán)境需要安裝對(duì)應(yīng)的32位兼容庫(kù)。3.3 逐行解讀為什么這么寫函數(shù)開頭三行值得認(rèn)真看push ebp、mov ebp, esp、mov ebx, [ebp 8]。這里涉及的就是“棧幀”的概念。CALL str_len執(zhí)行時(shí)CPU會(huì)把返回地址壓棧然后跳轉(zhuǎn)到函數(shù)入口進(jìn)入函數(shù)后push ebp保存調(diào)用者的棧基址mov ebp, esp把當(dāng)前棧頂設(shè)為新函數(shù)的棧底。接著訪問[ebp 8]就能拿到第一個(gè)參數(shù)。為什么偏移是8而不是4因?yàn)閺腅BP往上數(shù)先是本函數(shù)壓入的舊EBP4字節(jié)再是CALL壓入的返回地址4字節(jié)這兩項(xiàng)各占4字節(jié)所以第一個(gè)參數(shù)在偏移8的位置。這個(gè)計(jì)算邏輯一旦想清楚后面涉及多參數(shù)、局部變量的函數(shù)就不會(huì)暈。xor eax, eax這條指令是把EAX清零的慣用寫法。任何數(shù)與自身異或都會(huì)得到0所以這條指令等價(jià)于mov eax, 0但編碼更短對(duì)流水線也更友好。后來(lái)我看編譯器生成的代碼發(fā)現(xiàn)它同樣偏愛這種寫法這是最典型的“用數(shù)學(xué)性質(zhì)優(yōu)化代碼”的例子。cmp byte [ebx], 0這里的byte關(guān)鍵字很容易被漏寫。如果不寫B(tài)YTE匯編器根本不知道是拿一個(gè)字節(jié)、一個(gè)字還是雙字去跟0比較要么報(bào)錯(cuò)要么生成完全不符合預(yù)期的指令。這是初學(xué)匯編最常踩的坑之一。另外因?yàn)樽址厥且粋€(gè)字節(jié)所以指針inc ebx只移動(dòng)一個(gè)字節(jié)如果遍歷的是一個(gè)32位整數(shù)數(shù)組這里就得改成add ebx, 4。3.4 編譯鏈接中的幾個(gè)實(shí)際問題我自己第一次編譯時(shí)在64位Linux上直接gcc main.c str_len.o結(jié)果報(bào)了無(wú)數(shù)頭文件錯(cuò)誤原因就是默認(rèn)按64位鏈接而我的匯編目標(biāo)是32位。加上-m32之后又提示缺少32位運(yùn)行庫(kù)。裝好庫(kù)后才順利跑通。另外這個(gè)函數(shù)遵循的是cdecl調(diào)用約定參數(shù)從右往左壓棧由調(diào)用方清理?xiàng)！Ｎ以趨R編里沒有額外清理?xiàng)Ｒ驗(yàn)榍謇韯?dòng)作發(fā)生在C函數(shù)里如果用了stdcall約定按規(guī)則清棧的就是被調(diào)用方。這些約定細(xì)節(jié)下一章還會(huì)展開。如果運(yùn)行結(jié)果不是預(yù)期先別急著懷疑業(yè)務(wù)邏輯用調(diào)試器單步走一遍看EBX指向的地址內(nèi)容是否真是字符串、計(jì)數(shù)每次是否加1。調(diào)試器是匯編學(xué)習(xí)里最好的老師這一點(diǎn)無(wú)論怎么強(qiáng)調(diào)都不過分。4. 高級(jí)語(yǔ)言與匯編的對(duì)應(yīng)關(guān)系編譯器到底干了什么掌握了基本語(yǔ)法后下一步是建立“高級(jí)代碼 → 匯編”的映射直覺。這一章是我認(rèn)為學(xué)習(xí)性價(jià)比最高的部分因?yàn)樗茏屇銖摹皶?huì)寫匯編”進(jìn)階到“能讀懂編譯器”。4.1 函數(shù)調(diào)用時(shí)的棧幀機(jī)制上一章的str_len函數(shù)已經(jīng)展示了棧幀的雛形。完整來(lái)看一次函數(shù)調(diào)用的流程是這樣的調(diào)用方先把參數(shù)壓棧然后執(zhí)行CALLCALL會(huì)把返回地址壓棧并跳轉(zhuǎn)到函數(shù)入口被調(diào)用方繼續(xù)壓入舊的EBP把ESP復(fù)制到EBP建立自己的棧幀函數(shù)執(zhí)行完依次恢復(fù)EBP、執(zhí)行RET跳回返回地址最后調(diào)用方清理參數(shù)區(qū)。這套流程幾乎適用于所有主流語(yǔ)言編譯出的代碼。理解了它你就能解釋很多詭異現(xiàn)象為什么局部變量在函數(shù)返回后不能繼續(xù)使用因?yàn)槟菈K棧內(nèi)存已經(jīng)“釋放”了為什么棧溢出攻擊喜歡覆蓋返回地址因?yàn)榉祷氐刂肪痛嬖跅墓潭ㄎ恢?。在調(diào)試器里觀察棧幀時(shí)我建議重點(diǎn)關(guān)注EBP和ESP之間的關(guān)系。ESP隨時(shí)可能變化一旦壓棧出棧就會(huì)移動(dòng)EBP在函數(shù)生命周期內(nèi)基本不動(dòng)所以編譯器習(xí)慣以EBP為基準(zhǔn)去訪問參數(shù)和局部變量。這個(gè)視角能快速定位“為什么參數(shù)取出來(lái)的值不對(duì)”這類問題。4.2 調(diào)用約定跨語(yǔ)言協(xié)作的“合約”在匯編函數(shù)和C函數(shù)之間互調(diào)全靠調(diào)用約定維持秩序。我整理了三張最常見的“合約”約定名稱參數(shù)傳遞方式清棧責(zé)任cdecl參數(shù)從右往左壓棧調(diào)用方負(fù)責(zé)stdcall參數(shù)從右往左壓棧被調(diào)用方負(fù)責(zé)fastcall前兩個(gè)參數(shù)走寄存器其余壓棧視具體實(shí)現(xiàn)而定寫內(nèi)聯(lián)匯編或者匯編文件與C混合編譯時(shí)調(diào)用約定不匹配是崩潰的常見原因。我遇到過一次程序運(yùn)行正常但偶爾返回詭異值的Bug最后發(fā)現(xiàn)是匯編函數(shù)用了stdcall清理?xiàng)６鳦那邊按照cdecl再次清理兩條清理邏輯疊加把棧徹底搞亂了。從那以后我在每個(gè)匯編函數(shù)開頭都會(huì)用注釋寫明調(diào)用約定避免自己忘記。4.3 觀察編譯器優(yōu)化反匯編是最好的老師安裝了調(diào)試器之后建議做一個(gè)很直觀的小實(shí)驗(yàn)寫一個(gè)簡(jiǎn)單的C函數(shù)然后查看它對(duì)應(yīng)的匯編代碼。編譯器在優(yōu)化時(shí)做的一些事情往往比教科書里的示例更精彩。比如求一個(gè)數(shù)乘以10編譯器可能不會(huì)生成乘法指令而是生成(x 3) (x 1)因?yàn)橐莆缓图臃ū瘸朔ǜ?。再比如?shù)組下標(biāo)訪問編譯器會(huì)精心計(jì)算偏移盡量用一條尋址指令完成。這些優(yōu)化策略只有親眼看到匯編才體會(huì)得到。排查性能瓶頸時(shí)編譯器通常提供“輸出匯編文件”的選項(xiàng)。遇到熱點(diǎn)代碼性能不達(dá)標(biāo)看一眼它的匯編很多時(shí)候比盲猜快得多?？赡芸雌饋?lái)只是多了一條無(wú)謂的內(nèi)存讀或者某個(gè)循環(huán)沒被展開優(yōu)化方向立刻就清楚了。4.4 內(nèi)聯(lián)匯編是“手術(shù)刀”不是“菜刀”C語(yǔ)言等高級(jí)語(yǔ)言允許在代碼里直接嵌入?yún)R編片段這就是內(nèi)聯(lián)匯編。寫一個(gè)最簡(jiǎn)單例子int add_one(int x) { __asm__(addl $1, %0 : r(x)); return x; }這段代碼的意思是用一條addl指令把x加上1。功能上等價(jià)于x但如果你以為這樣就更“底層”、更快那就錯(cuò)了。我有一次在某段代碼里用手寫匯編“優(yōu)化”了一個(gè)局部變量的遞增結(jié)果這段匯編破壞了編譯器對(duì)寄存器的分配規(guī)則導(dǎo)致后續(xù)代碼的優(yōu)化全部失效整體性能反而下降。之后我就給自己立了一條規(guī)矩內(nèi)聯(lián)匯編是最后手段必須先用量化工具確認(rèn)瓶頸確實(shí)在這里再考慮動(dòng)它否則99%的情況讓編譯器自己優(yōu)化才是正途。5. 初學(xué)匯編的常見問題排查實(shí)錄這一章是實(shí)戰(zhàn)部分的整理。我特意把問題和排查思路按場(chǎng)景歸類方便你日后當(dāng)速查表用。5.1 一運(yùn)行就段錯(cuò)誤Segmentation Fault段錯(cuò)誤是匯編初學(xué)者遇到最多的崩潰形式。它的本質(zhì)是程序訪問了非法內(nèi)存地址。排查順序我建議這樣先檢查所有內(nèi)存訪問指令[...]里的寄存器值確認(rèn)地址是否合理再檢查字符串是否真的以0結(jié)尾如果遍歷了一個(gè)沒有終止符的數(shù)組很容易一路讀下去訪問到不可讀的地址最后檢查PUSH和POP是否配對(duì)棧不平衡會(huì)讓RET跳到錯(cuò)誤的地方。我自己曾寫出過“只PUSH不POP”的函數(shù)調(diào)用第二次時(shí)棧里累積了越來(lái)越多的垃圾數(shù)據(jù)程序表現(xiàn)是第一次調(diào)用正常、第二次隨機(jī)崩潰排查了很久才發(fā)現(xiàn)是棧清理缺失。5.2 循環(huán)只跑一次或者干脆變成死循環(huán)這類問題十有八九和寄存器沖突有關(guān)。ECX常被用作循環(huán)計(jì)數(shù)器但如果循環(huán)體內(nèi)調(diào)用了另一個(gè)函數(shù)那個(gè)函數(shù)也把ECX當(dāng)成臨時(shí)寄存器用了計(jì)數(shù)就被覆蓋。解決思路是約定好哪些寄存器在函數(shù)調(diào)用后不變嚴(yán)格遵守。這里就有必要記住caller-saved和callee-saved的概念。簡(jiǎn)單說某些寄存器的值在函數(shù)調(diào)用后很可能被改掉所以調(diào)用方要在調(diào)用前保護(hù)另一些寄存器由被調(diào)用方保護(hù)調(diào)用方可以放心使用。在匯編函數(shù)里如果需要保護(hù)某個(gè)寄存器就在函數(shù)開頭PUSH結(jié)尾POP形成完整的進(jìn)出平衡。5.3 數(shù)據(jù)定義寬度不對(duì)用匯編定義數(shù)據(jù)時(shí)dbdefine byte表示一個(gè)字節(jié)dw表示一個(gè)字2字節(jié)dd表示一個(gè)雙字4字節(jié)。很多人第一次寫字符串定義時(shí)用了dd導(dǎo)致每個(gè)字符被放成4字節(jié)整個(gè)內(nèi)存布局完全錯(cuò)亂遍歷結(jié)果自然一塌糊涂。正確寫法是字符串用db逐一存放msg: db hello, 0這里末尾的0就是字符串終止符。只要把數(shù)據(jù)寬度定義和內(nèi)存訪問寬度對(duì)齊很多“字符串讀取結(jié)果怪異”的問題都能避免。5.4 調(diào)試器的三板斧匯編開發(fā)中調(diào)試器比任何打印日志都靠譜。核心動(dòng)作其實(shí)就三個(gè)設(shè)置斷點(diǎn)在某條指令處暫停查看所有寄存器的當(dāng)前值按指定格式查看某塊內(nèi)存的內(nèi)容。遇到“我到底改沒改這個(gè)變量”這類問題在調(diào)試器里直接看內(nèi)存比在源碼里猜測(cè)快得多。寄存器里存儲(chǔ)的地址是多少、那片內(nèi)存的數(shù)據(jù)是什么一眼就能確認(rèn)。調(diào)試匯編沒有高級(jí)語(yǔ)言那么多隱藏邏輯一切都很“物理”步步可見。5.5 一條救命經(jīng)驗(yàn)先寫小函數(shù)再拼大系統(tǒng)新手特別容易一上來(lái)就寫幾百行匯編然后編譯報(bào)錯(cuò)卻不知道從何查起。我后來(lái)養(yǎng)成的習(xí)慣是每個(gè)函數(shù)單獨(dú)寫成獨(dú)立模塊配一個(gè)C語(yǔ)言的測(cè)試殼把輸入輸出打印出來(lái)確認(rèn)函數(shù)行為正確之后再組裝進(jìn)整個(gè)工程。匯編的調(diào)試成本遠(yuǎn)高于高級(jí)語(yǔ)言把驗(yàn)證粒度切得越小定位問題越容易。一次只驗(yàn)證一個(gè)函數(shù)的輸入輸出出錯(cuò)了范圍也小。那些在幾百行匯編里翻找“某條指令操作數(shù)寫反”的體驗(yàn)經(jīng)歷過一次就不會(huì)想再來(lái)一次。最后再分享一點(diǎn)個(gè)人體會(huì)我對(duì)匯編的態(tài)度一直很微妙日常工作里幾乎寫不到它但它給我建立的底層直覺幾乎每天都在發(fā)揮作用。排查內(nèi)存問題、理解性能計(jì)數(shù)器、閱讀崩潰日志里那幾行寄存器快照靠的都是當(dāng)年啃匯編時(shí)建立的模型。如果讓我給剛學(xué)匯編的人三個(gè)建議我會(huì)說第一寄存器就是一切的基礎(chǔ)先把它玩熟不要急著背所有指令第二每學(xué)一個(gè)指令就寫一個(gè)5到10行的迷你函數(shù)親眼看看運(yùn)行結(jié)果不要讓概念停留在紙面上第三遇到看不懂的代碼別硬背打開調(diào)試器跟著寄存器一步一步走比反復(fù)閱讀手冊(cè)有效得多。還有一個(gè)壓縮學(xué)習(xí)曲線的小技巧常用指令其實(shí)只有二三十條把高頻指令練到條件反射冷門指令用到時(shí)再查手冊(cè)就夠了。真正的能力不是背下所有指令而是知道一個(gè)功能大概需要哪些指令、能不能優(yōu)化、能優(yōu)化到什么程度。這個(gè)手感只有親手寫過匯編的人才會(huì)有。