RISC-V下gdb调试xv6执行ecall后trace丢失如何进入内核跟踪

trace丢失原因 #

• 符号加载不完整：你启动riscv64-unknown-elf-gdb时默认仅加载了alarmtest用户态程序的符号表，未加载xv6内核符号。ecall触发U模式到S模式的特权级切换后，PC会跳转到内核虚拟地址空间的uservec入口，当前gdb没有内核地址的映射与符号信息，无法识别对应地址的指令与内存，就会抛出内存访问错误。
• 调试器上下文未适配特权级切换：RISC-V架构U模式和S模式使用独立页表，gdb默认工作在用户态调试上下文，切换到内核态后仍使用用户态页表翻译地址，无法正确读取内核地址空间内容，你看到的0x64地址是地址翻译错误后的异常值，并非实际的内核PC值。

内核侧跟踪操作步骤 #

1. 启动gdb时优先加载内核符号
   不要直接以alarmtest作为入参启动gdb，先加载xv6内核二进制，再额外加载用户程序符号：

riscv64-unknown-elf-gdb kernel/kernel
# 进入gdb交互界面后加载alarmtest符号，xv6用户程序默认加载基地址为0x0
(gdb) add-symbol-file user/alarmtest 0x0

2. 提前在内核入口打断点，避免直接单步ecall
   不要在ecall指令执行后直接单步，提前在你需要跟踪的内核函数入口打硬件断点，比如：

# 在内核陷入入口打断点
(gdb) b uservec
# 也可以直接打sigalarm对应的系统调用处理函数断点
(gdb) b sys_sigalarm

断点设置完成后执行continue命令，gdb会自动停在对应的内核位置，此时即可正常单步跟踪内核侧的执行逻辑。

3. 可选适配配置
   如果你的gdb版本支持RISC-V特权级调试，可以执行以下配置提升调试体验：

(gdb) set architecture riscv:rv64
(gdb) set riscv use-non-stop on

注意：启动qemu时必须开启调试端口支持，xv6可以直接运行make qemu CPUS=1 GDB=1启动带调试支持的虚拟机，否则gdb无法连接到qemu的调试实例。

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