3. QEMU监控器与调试接口

调试RISC-V系统，说白了就是跟硬件和模拟器打交道。QEMU提供了三把利器：监控器、GDB远程调试、日志跟踪系统。这三样东西用熟了，定位问题就像开了上帝视角。

我个人习惯，先把监控器玩透，再上GDB，最后用日志系统做兜底。顺序别搞反了，不然容易抓瞎。

3.1 QEMU Monitor 基本命令

QEMU Monitor 是跟模拟器内核直接对话的接口。启动时加 -monitor stdio 就能在终端里用。我刚开始用的时候，总觉得这玩意儿就是个控制台，后来才发现它比我想象的强太多。

qemu-system-riscv64 -machine virt -kernel my_kernel.elf \
    -monitor stdio \
    -serial mon:stdio

进到 Monitor 后，常用的命令就这几类：

举个例子，你怀疑某个外设没映射对：

(qemu) info mtree
address-space: memory
  0000000000000000-0000000000000fff (prio 0, ram): riscv.virt.pflash
  0000000000100000-0000000000100fff (prio 0, i/o): riscv.sifive.uart
  0000000010000000-0000000010000fff (prio 0, i/o): riscv.clint

看到没？UART在0x100000，CLINT在0x10000000。如果驱动里写错了地址，这里一眼就能揪出来。

3.2 GDB 远程调试连接

GDB远程调试是重头戏。QEMU内置了GDB stub，启动时加 -s 或 -gdb tcp::1234 就能连上。

连接步骤很简单：

1. 启动QEMU：qemu-system-riscv64 -machine virt -kernel app.elf -s -S
2. 启动GDB：riscv64-unknown-elf-gdb app.elf
3. 在GDB里连：(gdb) target remote localhost:1234
4. 开始调试：(gdb) continue

-S 参数让CPU在启动时暂停，等你下好断点再跑。这个习惯我建议你养成，不然代码跑飞了都不知道从哪开始查。

调试RISC-V内核时，我最常用的GDB命令：

(gdb) monitor info registers
  ...
  mepc   0x80000100
  (gdb) set $pc = 0x80000100

3.3 QEMU 日志与跟踪系统

日志系统是调试的最后一层防线。当Monitor和GDB都搞不定的时候，就该上 -d 选项了。

启动时加 -d trace 就能看到QEMU内部的各种事件。我整理了一份常用日志选项：

举个例子，你怀疑中断没响应：

qemu-system-riscv64 -machine virt -kernel test.elf \
    -d int,cpu -D /tmp/qemu_trace.log

-D 把日志写到文件，不然终端刷屏你根本看不完。我习惯先跑一小段，然后grep关键信息：

grep -E "mip|mie|mtvec" /tmp/qemu_trace.log

(qemu) trace-event riscv_cpu_do_interrupt on
(qemu) trace-event riscv_cpu_do_interrupt off

3.4 常用调试技巧

最后分享几个实战技巧，都是我在项目里踩过坑后总结的。

技巧2：用QMP做自动化调试

QEMU Machine Protocol（QMP）是JSON格式的控制接口。启动时加 -qmp tcp:localhost:4444,server,nowait，然后用Python脚本控制：

import socket, json
sock = socket.socket()
sock.connect(('localhost', 4444))
# 发送QMP命令
cmd = {"execute":"query-cpus"}
sock.send(json.dumps(cmd).encode())
resp = sock.recv(4096)
print(json.loads(resp))

这个我用来做回归测试，跑完一个用例自动复位，比手动敲命令快多了。

技巧3：结合 -d guest_errors 和 GDB

先开日志跑一遍，看有没有 guest_errors。如果有，记下出错的PC地址，再用GDB在那个地址下断点。这样定位问题比瞎猜快十倍。