除錯介面卡協議的新家

Name: Visual Studio Code
Author: Microsoft

2018年8月7日 André Weinand，@weinand

七月里程碑的一個目標是將除錯介面卡協議——它一直“隱藏”在一個有點模糊的GitHub專案中——遷移到一個更醒目的網站（參見功能請求#19636）。

這篇部落格將提供關於協議、除錯介面卡協議以及此次遷移背後動機的一些背景資訊。

為什麼需要透過協議解耦？

摘自另一篇部落格

“Visual Studio Code 是面向任何開發者的編輯器，無論您使用何種程式語言。”

這一承諾基於（至少）兩個支柱：

從開發工具的角度支援一種程式語言意味著：

後者可能讓一些人感到驚訝，但我們一直堅信除錯是原始碼編寫地點的組成部分：編輯器。除錯是開發“內部迴圈”的重要組成部分。

但是，為新的語言向IDE或編輯器新增偵錯程式是一項重大的工作，因為標準除錯功能的列表並不短：

為新的語言實現這些功能不僅是一項重大工作，而且令人沮喪的是，這項工作必須針對每個開發工具重複進行，因為每個工具都使用不同的API來實現其使用者介面。

這導致了大量的重複功能（和實現），如下圖中的藍色方框所示：

without Debug Adapter Protocol

當我們開始 Visual Studio Code 的工作時，我們總是設想盡可能地將“前端”UI 與特定語言的“後端”實現解耦。我們希望對語言智慧和除錯支援都這樣做。

今天，我們相信我們已經實現了這個宏偉的目標：

我們建立了兩個抽象協議，允許將“前端”的編輯和除錯使用者介面與“後端”元件提供的特定語言智慧和除錯功能解耦。

“對語言的深入理解”由語言伺服器協議（LSP）呈現，“除錯支援”由除錯介面卡協議（DAP）呈現。

除錯介面卡協議背後的理念是標準化一個抽象協議，用於開發工具的除錯元件如何與具體的偵錯程式或執行時進行通訊。

由於假設現有偵錯程式或執行時會很快採用此協議是不現實的，因此我們設計了一個中間元件來承擔將現有偵錯程式或執行時API適配到除錯介面卡協議的角色。這個中間元件成為除錯介面卡，這解釋了協議的名稱：除錯介面卡協議。

下面是一個開發工具如何使用DAP與流行的“gdb”偵錯程式的除錯介面卡進行通訊的示例：

breakpoint

我們假設使用者已經啟動了除錯會話，但目前停留在程式入口點，並希望設定（並稍後命中）一個斷點。

使用者透過點選斷點槽在一個特定的原始檔中設定一個或多個斷點。開發工具向除錯介面卡傳送一個setBreakpoints請求，除錯介面卡將該斷點註冊到gdb偵錯程式。
然後使用者按下繼續按鈕以恢復執行。工具向除錯介面卡傳送一個continue請求，除錯介面卡將其轉換為相應的gdb命令。
一段時間後，斷點被命中，除錯介面卡從gdb接收到一些通知，並將其轉換為一個DAP stopped事件，該事件被髮送到開發工具。
響應此stopped事件，開發工具更新其UI並顯示堆疊跟蹤檢視。這會觸發一個stacktrace請求，該請求返回為單個堆疊幀顯示的所有資訊。
如果使用者選擇一個堆疊幀，開發工具會透過variables請求該幀的變數。