2026.05.23-工作周记

[Irissssaa]

开发日志

一、StarryOS 调试适配工作总结

1. **边界断点 bug 修复**

• 问题描述

  调试器使用函数名方式配置边界断点（{ "fun ction": "enter_user" }）时，调试器会在 enter_user 处意外停下，并且按继续后反复停在同一位置，出不去。

• 核心问题

  • 问题一：边界断点生命周期管理遗漏（未被清理）

    现象： 调试器在切换至用户态（User 组）后，理应清理内核态的边界断点。但由于函数名断点（如 enter_user）是通过底层 GDB 命令直接插入的，绕过了 BreakpointGroups 的统一管理，导致其在状态切换时未被正常清除。

    结果： 当用户程序发起系统调用（Syscall）切回内核时，直接命中了残留的 enter_user 断点。由于此时状态机处于用户态，调试器将其误判为普通断点并暂停程序，导致控制流异常中断。

  • 问题二：状态机陷入单向停滞（缺少 User-to-Kernel 边界）

    现象： Starry OS 原本未配置“用户态至内核态”的边界断点。

    结果： 导致程序在系统调用返回内核时，状态机始终停留在 User 态，无法触发 AT_USER_TO_KERNEL_BORDER 到 AT_KERNEL 的正常状态流转。后续的执行逻辑一直错误地沿用用户态的处理流程。

• 解决方案

  问题一是简单的bug，很好修改，但是对于问题二，涉及到调试器的边界断点设计问题，根据分析与测试，最终采用的解决方案是引入“边界断点方向字段（Direction: UserToKernel / KernelToUser）”，下面是问题说明：

  • rCore和Starry OS对比

    在多态（用户态/内核态）OS 调试器的设计中，依赖边界断点（Border Breakpoint）作为状态机切换断点组的触发信号。

    • rCore 模式（基于源码路径）： 教学 OS，其内核与用户态源码同属一个工作区。调试器可通过“文件路径+行号”隐式区分断点归属（如 user/src/ 归用户组，os/src/ 归内核组），状态机方向天然明确。

    • Starry OS 模式（基于符号表与函数名）： 工业级 OS 架构，用户程序为外部动态加载的 ELF 二进制文件，无本地源码路径。调试器只能通过“函数名”设置边界断点，导致原有的路径隐式归组机制失效。

  • 为何必须将“user->kernel 边界断点”设在内核态？

    在无法使用文件路径的情况下，我验证了“在用户态发起系统调用的源头打断点”是不可行的，必须退守内核态统一拦截，原因有二：

    • 符号生命周期限制（根本原因）： 用户程序是动态加载的，调试器初始化时其符号表尚未就绪。若强行在用户态设点，GDB 会因“无符号”将其挂起为暂态断点，导致断点注入极不稳定。
    • 入口多样性导致无法收敛（架构原因）： 用户态触发 syscall 的方式高度碎片化（如 libc 封装、自定义 Rust 接口、纯内联汇编等）。调试器无法穷举拦截，只能选择所有系统调用必然汇聚的内核统一入口（即 handle_syscall）。

  • 为什么必须引入“方向（Direction）”属性？

    由于上述物理与架构限制，我们被迫放弃用户态设点，将“用户 $\rightarrow$ 内核”的陷入点（handle_syscall）与“内核 $\rightarrow$ 用户”的退出点（enter_user）全部设置在内核层。这引发了严重的逻辑重叠：

    • 特权级双向行为的地址重叠： 进、出两个边界断点在物理上均位于内核地址空间。
    • 状态机丧失流向判断能力： 当程序命中这两种边界断点而暂停时，由于当前内存空间皆为内核态，状态机无法推断程序当前的真实执行流向。
    • 导致调试器死循环崩溃： 这种流向歧义导致了调试失败的两个致命结果：一是状态机单向停滞在 User 态无法切回 Kernel 态；二是内核态边界断点在切换后未被清理，导致下一次执行时被误判为普通断点，陷入死循环。

  通过隐式手段已无法满足组件化 OS 的跨特权级调试需求。显式引入“边界断点方向字段（Direction: UserToKernel / KernelToUser）”是保障状态机精确切换的最好办法。

2. hook断点无法获取到文件名：

   # 调试控制台输出
   args=[{name="path",value="<optimized out>"}]

   通过这个内容知道是因为path被优化了，需要 make=debug 获取调试信息。

   最开始尝试 make MODE=debug，结果make run不了，卡在下面的地方了：

   

   可能是因为debug的编译产物太大了，加载需要很久，然后我就想试试修改 OS 的Cargo.toml内容：

   

   但还是会被优化，然后就想修改OS的源代码，在path的源代码处，还是遇到一些问题，等待下一步尝试。

二、会议内容

1. 问一下StarryOS的debug版启动不了；
2. 上传日志；
3. 调试打通后，实现调试器自动识别边界断点和hook断点（无人介入）。