【开发日志】第二十六周（2025.10.26）

[Irissssaa]

工作内容

调试rCore

复现调试工作，录视频，遇到的问题记录

1. 刚开始尝试之前复现好的rcore进行调试，但是发现手动打断点位置会偏移，或者打不上，并且调试器始终无法命中用户态的断点。

   对于前面一个问题吴老师提出可能是编译的问题，尝试重新编译还是不行，后来注意到编译文件是release模式的，我想可能是内联优化导致的，于是将编译参数改成了debug，断点确实可以打上了，但还是无法调试用户态（用户态的断点无法命中），并且rcore直接跑不起来了，询问学长才得知这个是 rcore 的 bug，并且学长提供新思路，他们之前是通过修改编译选项的其他参数来减少在release模式下的编译优化，于是我参考23年的参赛文档开展了工作。

2. 文档中有提到两个方法：a. 他们将编译优化的修改打包成了补丁，可以使用；b. 学长git有维护一个可以直接使用的rCore-Tutorial-v3

但是不好的消息是，这两个我都试过，均不可用，原因如下：

（1）补丁是在之前版本的rcore 基础上进行修改的，现在的 rcore 源代码已经进行了更新，无法直接使用补丁文件（patch的缺点）

（2）学长他们的rCore仓库不清楚是什么原因，我尝试同样调试不了用户态

不过我去查看了学长仓库的rCore- tutorial-v3 的 commit，果然看到了他们当时提交的和补丁相关的 commit，现在新的思路是切换到这个commit，再进行尝试。

但是同样无法命中用户态的断点。

第二阶段：学长帮忙发现 getStringVariable 函数的问题，我也相应解决后，出现了新的问题，就是钩子断点第一次触发就直接得到了 "user_shell"，错过了 initproc 阶段，这导致 initproc.rs 断点无法工作，如图：

具体原因并不清楚，然后我就在想是不是钩子断点设置的不对，经过一番实验和思考，猜测原因可能是：

• 由于 rCore 内核启动速度过快，插件在尝试切换到 initproc 的过程中，被 initproc 自身触发的 exec("user_shell") 打断，导致内部目标被错误地覆盖为 user_shell，从而未能正确跟踪 initproc 的执行，也使得 initproc.rs 中的断点无效

于是我通过取消process.rs:49 钩子 ，就移除了覆盖目标的机会，好消息是initproc目标被识别到了，如图：

但是断点还是没有被命中，可能是因为调试器还没来得及切换断点组，initproc.rs的程序就已经运行完了，但是我不知道怎么去解决这个问题。

调试ucore 面临的问题如下：

ucore的前4个lab是不涉及内核和用户态的切换的，所以直接使用gdb即可调试，但是之前没有考虑到因为每一个lab的边界断点和钩子所在的行号是不同的，所以需要为每一个lab编写launch.json，但是由于我对ucore不熟，所以目前调试遇到一些问题。

会议内容

Q1：零号进程无法打断点

Q2：补丁

Q3：写一个自动关闭vs code终端的函数

Q4：边界断点问题导致的无法跟踪initproc程序（已解决）