[[399391]]

本文轉(zhuǎn)載自微信公眾號「神光的編程秘籍」，作者神說要有光zxg。轉(zhuǎn)載本文請聯(lián)系神光的編程秘籍公眾號。

代碼寫完會運行一下看下效果，開發(fā)的時候我們更多都是通過 dubugger 來單步或斷點運行。我們整天在用 debugger，可是你有想過它的實現(xiàn)原理么。

本文會解答以下問題：

• 代碼運行的底層原理是什么
• 為什么需要 debugger
• debugger 實現(xiàn)原理是什么
• 如何實現(xiàn) debugger 客戶端

代碼運行的原理是什么

代碼的運行方式可以分為直接執(zhí)行和解釋執(zhí)行兩類。

不知道平時你有沒有注意，可執(zhí)行文件直接 ./xxx 就可以執(zhí)行，而執(zhí)行 js 文件需要 node ./xxx，執(zhí)行 python 文件需要 python ./xxx，這就是編譯執(zhí)行(直接執(zhí)行)和解釋執(zhí)行的區(qū)別。

直接執(zhí)行

cpu 提供了一套指令集，基于這套指令集就可以控制整個計算機的運轉(zhuǎn)，機器語言的代碼就是由這些指令和對應(yīng)的操作數(shù)構(gòu)成的，這些機器碼可以直接跑在計算機上，也就是可直接執(zhí)行。由它們構(gòu)成的文件叫做可執(zhí)行文件。

不同操作系統(tǒng)可執(zhí)行文件的格式不同，在 windows 上是 pe(Portable Executable) 格式，在 linux、unix 系統(tǒng)上是 elf(Executable Linkable Format) 格式，在 mac 上是 mash-o 格式。它們規(guī)定了不同的內(nèi)容(.text 是代碼、.data .bass 等是數(shù)據(jù))放在文件中的什么位置。但其中真正可執(zhí)行的部分還是由 cpu 提供的機器指令構(gòu)成的。

編譯型語言會經(jīng)過編譯、匯編、鏈接的階段，編譯是把源代碼轉(zhuǎn)成匯編語言構(gòu)成的中間代碼，匯編是把中間代碼變成目標(biāo)代碼，鏈接會把目標(biāo)代碼組合成可執(zhí)行文件。這個可執(zhí)行文件是可以在操作系統(tǒng)上直接執(zhí)行的。就因為它是由 cpu 的機器指令構(gòu)成的，可以直接控制 cpu。所以可以直接 ./xxx 就可以執(zhí)行。

解釋執(zhí)行

編譯型語言都是生成可執(zhí)行文件直接在操作系統(tǒng)上來執(zhí)行的，不需要安裝解釋器，而 js、python 等解釋型語言的代碼需要用解釋器來跑。

為什么有了解釋器就不需要生成機器碼了，cpu 仍然不認識這些代碼啊?

那是因為解釋器是需要編譯成機器碼的，cpu 知道怎么執(zhí)行解釋器，而解釋器知道怎么執(zhí)行更上層的腳本代碼，就這樣，由機器碼解釋執(zhí)行解釋器，再由解釋器解釋執(zhí)行上層代碼，這就是腳本語言的原理。 包括 js、python 等都是這樣。

但是解釋器畢竟多了一層，所以有的時候會把它編譯成機器碼來直接執(zhí)行，這就是 JIT 編譯器。比如 js 引擎一般就是由 parser、解釋器、JIT 編譯器、GC 構(gòu)成，大部分代碼是由解釋器解釋執(zhí)行的，而熱點代碼會經(jīng)過 JIT 編譯器編譯成由機器碼，直接在操作系統(tǒng)上執(zhí)行以提高性能。

編譯成機器碼直接執(zhí)行，或者是從源碼解釋執(zhí)行，代碼就這兩種執(zhí)行方式。兩者各有各的好處，編譯型速度快，解釋型跨平臺。這就是代碼運行的原理。

王垠說過，計算機的本質(zhì)就是解釋器。就是說 cpu 用電路解釋機器碼，解釋器用機器碼解釋更上層的腳本代碼，所以計算機的本質(zhì)是解釋器。

為什么需要 debugger

我們知道，圖靈完備的語言可以解釋任何可計算問題，所以不管是編譯型還是解釋型都能夠描述所有可計算的業(yè)務(wù)邏輯。

我們利用不同的語言描述業(yè)務(wù)邏輯，然后運行它看效果，當(dāng)代碼的邏輯比較復(fù)雜的時候，難免會出錯，我們希望能夠一步步運行或是運行到某個點停下來，然后看一下當(dāng)時的環(huán)境中的變量，執(zhí)行某個腳本。完成這個功能的就是 debugger。

也許還有很多初級程序員只會用 console.log 打日志，但是日志不能完全展現(xiàn)當(dāng)時的環(huán)境，最好的方式還是 debugger。

狼叔說過，是否會用 debugger 是 nodejs 水平的一個明顯的區(qū)分。

debugger 的原理

我們知道了 debugger 是調(diào)試程序必不可少的，那么它是怎么實現(xiàn)的呢?

可執(zhí)行文件的 debugger

其實 cpu、操作系統(tǒng)在設(shè)計的時候就支持了 debugger 的能力(可見 debugger 的重要性)，cpu 里面有 4 個寄存器可以做硬中斷，操作系統(tǒng)提供了系統(tǒng)調(diào)用來做軟中斷。這是編譯型語言的 debugger 實現(xiàn)的基礎(chǔ)。

中斷

cpu 只會不斷的執(zhí)行下一條指令，但程序運行過程中難免要處理一些外部的消息，比如 io、網(wǎng)絡(luò)、異常等等，所以設(shè)計了中斷的機制，cpu 每執(zhí)行完一條指令，就會去看下中斷標(biāo)記，是否需要中斷了。就像 event loop 每次 loop 完都要檢查下是否需要渲染一樣。

INT 指令

cpu 支持 INT 指令來觸發(fā)中斷，中斷有編號，不同的編號有不同的處理程序，記錄編號和中斷處理程序的表叫做中斷向量表。其中 INT 3 (3 號中斷)可以觸發(fā) debugger，這是一種約定。

那么可執(zhí)行文件是怎么利用這個 3 號中斷來 debugger 的呢?其實就是運行時替換執(zhí)行的內(nèi)容，debugger 程序會在需要設(shè)置斷點的位置把指令內(nèi)容換成 INT 3，也就是 0xCC，這就斷住了。就可以獲取這時候的環(huán)境數(shù)據(jù)來做調(diào)試。

通過機器碼替換成 0xcc (INT 3)是把程序斷住了，可是怎么恢復(fù)執(zhí)行呢?其實也比較簡單，把當(dāng)時替換的機器碼記錄下來，需要釋放斷點的時候再換回去就行了。

這就是可執(zhí)行文件的 debugger 的原理了，最終還是靠 cpu 支持的中斷機制來實現(xiàn)的。

中斷寄存器

上面說的 debugger 實現(xiàn)方式是修改內(nèi)存中的機器碼的方式，但有的時候修改不了代碼，比如 ROM，這種情況就要通過 cpu 提供的 4 個中斷寄存器(DR0 - DR3)來做了。這種叫做硬中斷。

總之，INT 3 的軟中斷，還有中斷寄存器的硬中斷，是可執(zhí)行文件實現(xiàn) debugger 的兩種方式。

解釋型語言的 debugger

編譯型語言因為直接在操作系統(tǒng)之上執(zhí)行，所以要利用 cpu 和操作系統(tǒng)的中斷機制和系統(tǒng)調(diào)用來實現(xiàn) debugger。但是解釋型語言是自己實現(xiàn)代碼的解釋執(zhí)行的，所以不需要那一套，但是實現(xiàn)思路還是一樣的，就是插入一段代碼來斷住，支持環(huán)境數(shù)據(jù)的查看和代碼的執(zhí)行，當(dāng)釋放斷點的時候就繼續(xù)往下執(zhí)行。

比如 javascript 中支持 debugger 語句，當(dāng)解釋器執(zhí)行到這一條語句的時候就會斷住。

解釋型語言的 debugger 相對簡單一些，不需要了解 cpu 的 INT 3 中斷。

debugger 客戶端

上面我們了解了直接執(zhí)行和解釋執(zhí)行的代碼的 debugger 分別是怎么實現(xiàn)的。我們知道了代碼是怎么斷住的，那么斷住之后呢?怎么把環(huán)境數(shù)據(jù)暴露出去，怎么執(zhí)行外部代碼?

這就需要 debugger 客戶端了。

比如 v8 引擎會把設(shè)置斷點、獲取環(huán)境信息、執(zhí)行腳本的能力通過 socket 暴露出去，socket 傳遞的信息格式就是 v8 debug protocol 。

比如：

設(shè)置斷點：

{ 
    "seq":117, 
    "type":"request", 
    "command":"setbreakpoint", 
    "arguments":{ 
        "type":"function", 
        "target":"f" 
    } 

去掉斷點：

{ 
    "seq":117, 
    "type":"request", 
    "command":"clearbreakpoint", 
    "arguments": { 
        "type":"function", 
        "breakpoint":1 
     } 
} 

繼續(xù)：

{ 
    "seq":117, 
    "type":"request", 
    "command":"continue" 
} 

執(zhí)行代碼：

{ 
    "seq":117, 
    "type":"request", 
    "command":"evaluate", 
    "arguments":{ 
        "expression":"1+2" 
    } 
} 

感興趣的同學(xué)可以去 v8 debug protocol 的文檔中去查看全部的協(xié)議。

基于這些協(xié)議就可以控制 v8 的 debugger 了，所有的能夠?qū)崿F(xiàn) debugger 的都是對接了這個協(xié)議，比如 chrome devtools、vscode debugger 還有其他各種 ide 的 debugger。

nodejs 代碼的調(diào)試

nodejs 可以通過添加 --inspect 的 option 來做調(diào)試(也可以是 --inspect-brk，這個會在首行就斷住)。

它會起一個 debugger 的 websocket 服務(wù)端，我們可以用 vscode 來調(diào)試 nodejs 代碼，也可以用 chrome devtools 來調(diào)試(見 nodejs debugger 文檔)。

➜ node --inspect test.js 
Debugger listening on ws://127.0.0.1:9229/db309268-623a-4abe-b19a-c4407ed8998d 
For help see https://nodejs.org/en/docs/inspector 

原理就是實現(xiàn)了 v8 debug protocol。

我們?nèi)绻约鹤稣{(diào)試工具、做 ide，那就要對接這個協(xié)議。

debugger adaptor protocol

上面介紹的 v8 debug protocol 可以實現(xiàn) js 代碼的調(diào)試，那么 python、c# 等肯定也有自己的調(diào)試協(xié)議，如果要實現(xiàn) ide，都要對接一遍太過麻煩。所以后來出現(xiàn)了一個中間層協(xié)議，DAP(debugger adaptor protocol)。

debugger adaptor protocol， 顧名思義，就是適配的，一端適配各種 debugger 協(xié)議，一端提供給客戶端統(tǒng)一的協(xié)議。這是適配器模式的一個很好的應(yīng)用。

總結(jié)

本文我們學(xué)習(xí)了 debugger 的實現(xiàn)原理和暴露出的調(diào)試協(xié)議。

首先我們了解了代碼兩種運行方式：直接執(zhí)行和解釋執(zhí)行，然后分析了下為什么需要 debugger。

之后探索了直接執(zhí)行的代碼通過 INT 3 的中斷的方式來實現(xiàn) debugger 和解釋型語言自己實現(xiàn)的 debugger。

然后 debugger 的能力會通過 socket 暴露給客戶端，提供調(diào)試協(xié)議，比如 v8 debug protocol，各種客戶端包括 chrome devtools、ide 等都實現(xiàn)了這個協(xié)議。

但是每種語言都要實現(xiàn)一次的話太過麻煩，所以后來出現(xiàn)了一個適配層協(xié)議，屏蔽了不同協(xié)議的區(qū)別，提供統(tǒng)一的協(xié)議接口給客戶端用。

希望這篇文章能夠讓你理解 debugger 的原理，如果要實現(xiàn)調(diào)試工具也知道怎么該怎么去對接協(xié)議。能夠知道 chrome devtools、vscode 為啥都可以調(diào)試 nodejs 代碼。