Hulo 语言开发分享 调试器是如何工作的？

书接上回，在《 Hulo 编程语言开发 解释器》一文中，我们介绍了Hulo 编程语言的解释器。今天，让我们深入探讨编译流程中的第四个关键环节调试器。

调试器是编程语言开发中不可或缺的工具，它允许开发者暂停程序执行、检查变量状态、单步执行代码等。而它的核心是断点机制，它允许程序在特定位置暂停执行，并查看环境情况。

断点

断点本质上就是一个位置标记：

type Breakpoint struct { File string // 文件名 Line int // 行号 Column int // 列号 Condition string // 条件表达式（可选） Enabled bool // 是否启用 } 

调试器会收集用户指定要中断的位置，然后存储起来，待解释器走到那一步的时候暂停。

从 AST 到行列号

在解析器分析 AST 的时候，我们往往会为 AST 节点添加位置信息：

type Node interface { Pos() token.Pos End() token.Pos } 

每个 AST 节点都有两个关键方法：

• Pos() - 返回节点在源代码中的开始位置
• End() - 返回节点在源代码中的结束位置

具体例子：

1. 数字字面量 10：

type NumericLiteral struct { ValuePos token.Pos // 数字开始的位置 Value string // "10" } func (x *NumericLiteral) Pos() token.Pos { return x.ValuePos // 返回数字开始位置 } func (x *NumericLiteral) End() token.Pos { return token.Pos(int(x.ValuePos) + len(x.Value)) // 开始位置 + 长度 } 

1. 标识符 x：

type Ident struct { NamePos token.Pos // 标识符开始位置 Name string // "x" } func (x *Ident) Pos() token.Pos { return x.NamePos // 返回标识符开始位置 } func (x *Ident) End() token.Pos { return token.Pos(int(x.NamePos) + len(x.Name)) // 开始位置 + 长度 } 

位置转换过程：

实际上，计算行列号最简单的方法就是字符串分割：

func (d *Debugger) getLineFromPos(pos token.Pos) int { // 获取文件内容 content := d.getFileContent() // 将内容按行分割 lines := strings.Split(content, "\n") // 计算 pos 在第几行 currentPos := 0 for i, line := range lines { lineLength := len(line) + 1 // +1 是因为分割符 \n if currentPos <= int(pos) && int(pos) < currentPos + lineLength { return i + 1 // 返回行号（从 1 开始） } currentPos += lineLength } return 1 // 默认返回第 1 行 } func (d *Debugger) getColumnFromPos(pos token.Pos) int { // 获取文件内容 content := d.getFileContent() // 将内容按行分割 lines := strings.Split(content, "\n") // 计算 pos 在第几列 currentPos := 0 for _, line := range lines { lineLength := len(line) + 1 if currentPos <= int(pos) && int(pos) < currentPos + lineLength { // 计算在当前行中的偏移 return int(pos) - currentPos + 1 // 返回列号（从 1 开始） } currentPos += lineLength } return 1 // 默认返回第 1 列 } 

实际例子：

假设我们有代码：

fn main() { // 第 1 行 let x = 10 // 第 2 行 } 

文件内容："fn main() {\n let x = 10\n}"

• let 关键字：token.Pos(15)

  • 第 1 行长度：len("fn main() {") = 12，加上\n = 13
  • 第 2 行开始位置：13
  • 15 - 13 + 1 = 3，所以let在第 2 行第 3 列

• x 标识符：token.Pos(19)

  • 19 - 13 + 1 = 7，所以x在第 2 行第 7 列

• 10 数字：token.Pos(23)

  • 23 - 13 + 1 = 11，所以10在第 2 行第 11 列

Ps. 实际的代码和介绍的肯定不一样，不会写成这样。只是这样计算更直观，方便讲解。

断点匹配：检查是否命中

有了断点、位置转换和环境管理，现在我们可以实现完整的断点机制：

解释器在每个语句执行前都要调用断点检查：

func (interp *Interpreter) Eval(node ast.Node) ast.Node { // 关键：每个节点执行前检查断点 if interp.shouldBreak(node) { // 程序暂停，等待调试器命令 interp.pause() } // 正常执行逻辑... switch node := node.(type) { case *ast.Literal: return interp.evalLiteral(node) case *ast.BinaryExpr: return interp.evalBinaryExpr(node) // ... } } 

暂停机制：如何让程序停下来

当命中断点时，程序需要暂停等待调试器命令：

func (d *Debugger) pause() { d.isPaused = true // 发送暂停信号到调试循环 d.pauseChan <- struct{}{} // 关键：主线程在这里等待恢复信号 for d.isPaused { // 阻塞等待，直到调试器发送恢复命令 time.Sleep(10 * time.Millisecond) // 避免 CPU 空转 } } 

这里我们使用 pauseChan 变量作为暂停信号管道。当命中断点时，向管道发送信号，这个信号会在调试循环中接收并等待命令。

func (d *Debugger) debugLoop() { for { select { case <-d.ctx.Done(): return // 调试器关闭信号 case <-d.pauseChan: // 程序暂停了，开始等待用户命令 d.waitForResume() case cmd := <-d.commandChan: d.handleCommand(cmd) // 调试命令 } } } func main() { // ... go d.debugLoop() interp.Eval(node) // ... } 

调试循环可以理解为一个协程/线程，它在调试器启动的时候就会开始运行，与解释器的执行异步，这样双方就不会相互卡住。

• 主线程：执行 Hulo 代码，遇到断点时发送信号
• 调试协程：监听信号，处理调试命令，控制程序暂停/恢复

当程序命中断点时，主线程向pauseChan发送信号，调试协程的 select 语句检测到这个信号，立即调用waitForResume()开始等待用户命令。

waitForResume 的阻塞机制：

func (d *Debugger) waitForResume() { for d.isPaused { select { case cmd := <-d.resumeChan: d.handleCommand(cmd) if cmd.Type == CmdContinue { d.isPaused = false break // 退出等待，主线程可以继续 } } } } 

waitForResume()会一直阻塞在select语句上，直到从resumeChan接收到继续执行的命令。

完整的执行流程：

1. 主线程执行 → 命中断点 → 调用pause() → 卡住等待
2. 调试协程 → 接收到暂停信号 → 等待用户命令
3. 用户操作 → 发送继续命令 → 调试协程设置isPaused = false
4. 主线程 → 检测到isPaused = false → 继续执行

DAP 协议

DAP (Debug Adapter Protocol) 是微软开发的一个标准化调试协议，它定义了调试器与 IDE 之间的通信规范。

为什么需要 DAP ？

想象一下，如果你写了一个调试器，但是只能在命令行使用，那多不方便。用户想要在 VS Code 、IntelliJ IDEA 等图形化编辑器中调试代码，怎么办呢？

DAP 就是解决这个问题的。它就像是一个"翻译官"，把 IDE 的调试命令翻译成调试器能理解的语言，再把调试器的反馈翻译成 IDE 能显示的信息。

DAP 消息格式

DAP 使用 JSON 格式进行通信，就像两个人用同一种语言交流：

{ "type": "request", "seq": 1, "command": "setBreakpoints", "arguments": { "source": { "path": "/path/to/file.hl" }, "breakpoints": [ { "line": 10, "condition": "x > 5" } ] } } 

这个 JSON 消息的意思是："请在文件/path/to/file.hl的第 10 行设置一个断点，条件是x > 5"。

DAP 事件

调试器会向 IDE 发送各种事件，告诉 IDE 发生了什么：

{ "type": "event", "seq": 2, "event": "stopped", "body": { "reason": "breakpoint", "threadId": 1, "allThreadsStopped": true } } 

这个 JSON 消息的意思是："程序暂停了，原因是命中了断点"。

改造调试器

有了 DAP 协议，我们就可以在 VS Code 等编辑器中以图形化的方式控制我们的调试器。其实就是通过网络的方式向调试循环发送命令，本着简单原则我们再次改造下上文介绍的伪代码部分：

func main() { // 启动 DAP 服务器，监听来自 IDE 的连接 go d.startDAPServer() // 启动调试循环，处理调试命令 go d.debugLoop() // 开始执行程序 interp.Eval(node) } 

实际工作流程:

1. IDE 连接 - VS Code 连接到 Hulo 的 DAP 服务器/li>
2. 用户操作 - 用户在 VS Code 中点击"设置断点"
3. 发送命令 - VS Code 发送 JSON 命令到 DAP 服务器
4. 调试器处理 - Hulo 调试器接收命令并设置断点
5. 程序执行 - 程序运行到断点处暂停
6. 发送事件 - 调试器发送"程序暂停"事件给 VS Code
7. 界面更新 - VS Code 显示程序已暂停，用户可以查看变量

这就是现代调试器的标准做法：用统一的协议让不同的工具能够互相配合工作。