MIT6.S081自学阶段GDB远程调试异常问题求助

我之前做6.S081实验的时候也碰到过几乎一模一样的问题，结合官方实验文档和自己踩过的坑，给你几个亲测有效的解决步骤：

1. 修正GDB符号加载的顺序与方式 #

你的.gdbinit里默认加载了kernel/kernel的符号，但调试用户程序时，混合加载内核和用户程序符号会导致GDB符号解析混乱。建议调整调试流程：

• 先临时注释掉.gdbinit里的symbol-file kernel/kernel行，或者直接重命名.gdbinit（比如mv .gdbinit .gdbinit.bak）
• 确保用make qemu-gdb启动QEMU，这个命令会自动开启26000端口的调试服务
• 启动GDB后，先执行基础配置并连接目标：

  set architecture riscv:rv64
  target remote 127.0.0.1:26000
  set disassemble-next-line auto
  set riscv use-compressed-breakpoints yes
  

• 再加载用户程序的符号：

  file user/_primes
  

• 最后设置断点并运行：

  b main
  continue
  

2. 解决"cannot find bounds of current function"错误 #

这个错误通常是GDB无法正确解析用户程序的栈帧或符号信息，你可以添加两个关键配置：

• 在GDB中执行：

  set riscv force-ilp32 no
  set print frame-arguments all
  

• 同时确保你的用户程序是用实验提供的Makefile编译的——实验Makefile已经默认添加了-g调试符号和适配RISC-V的编译参数，手动修改编译选项很容易导致符号丢失。

3. 调试自定义find程序无响应的排查 #

如果调试自己写的程序时终端无响应，先分两步排查：

• 先脱离GDB，用make qemu直接运行find程序，看它是否能正常执行。如果QEMU里直接运行就卡住，那问题出在程序代码本身，比如死循环、系统调用参数错误；
• 如果QEMU里能正常运行，那在GDB里尝试先设置b _start（用户程序的早期入口点，比main更早），然后continue，再逐步步进至main，定位是哪个环节卡住的；
• 另外检查你的find程序是否正确链接了实验提供的用户库，实验Makefile会自动处理ulib.o、usys.o等依赖，手动编译时容易遗漏。

4. 验证GDB版本兼容性 #

你的GDB版本是9.2，虽然官方声称支持RISC-V，但旧版本的GDB对RISC-V用户程序的调试支持存在一些bug。Ubuntu 20.04可以通过以下命令升级到更稳定的10.x版本：

sudo apt install gdb-multiarch=10.1-2ubuntu2

升级后很多符号解析的问题会自动解决。

最后给你一个完整的调试_primes的命令序列参考：

# 启动GDB后先执行基础配置
set architecture riscv:rv64
target remote 127.0.0.1:26000
set disassemble-next-line auto
set riscv use-compressed-breakpoints yes
set riscv force-ilp32 no
set print frame-arguments all

# 加载用户程序符号
file user/_primes

# 设置断点并运行
b main
continue

# 现在执行n就应该能正常步进了
n

内容的提问来源于stack exchange，提问作者Jam