2026.05.30-工作周记

[Irissssaa]

工作内容

1. 边界断点相关问题

• OSStatus = user 没有 AT_KERNEL 处理器，导致 user_to_kernel 边界断点设在内核态 的情况不能完成状态转换（user->kernel）;
• function-based border 这个形式，边界断点只注册到了内核态，用户态的时候并没有边界断点，导致 user->kernel 无法触发边界断点。

下面是工作具体阐述：

上一次说的变量优化的问题并不是造成调试失败的主要原因，在当前来看，hook根本就没有触发，并且user_to_kernel就没成功，虽然引入了detraction属性。

通过检查相关逻辑，核心问题是：OSStatus = user 时，OS切换到内核态时触发 handle_syscall 边界断点，此时PC已经在kernel了，不需要单步到kernel，而是直接切换成kernel，但是user态我们并没有实现AT_KERNEL 处理器（让OSStatus=kernel，切换断点组），导致断点组切换失败。

所以解决这个问题即可，即在user态实现 AT_KERNEL 处理器。

紧接着，还有另一个问题，看通知顺序，handle_system并没有被触发，由于兜底行为才成功切换了OSStatus。

具体来说： debug-ready 时遍历 functionBorderNames，对每个函数名调用 addBreakPoint，然后把 gdbNumber 存回 getCurrentBreakpointGroup().borders 里对应的 Border 对象。但是getCurrentBreakpointGroup() 此时是 kernel 组，所以 gdbNumber 只存到了 kernel 组的 Border 对象里。

上面关于边界断点的bug解决后，通过通知检查，边界断点成功注入，并完成断点组切换。

2. hook 断点 getStringVariable('path') 失败

详见：hook 行为函数难点解决.md

3. launch.json的断点组返回配置问题

调试 StarryOS 时，用户程序断点无法命中。

调试过程：

1. 最初怀疑是状态机卡在内核态——通过 VSCode 断点调试追踪状态转换，发现状态机工作正常，kernel/user
   之间切换无误。
2. 深入追踪发现根因是断点组名称不匹配：

• 设断点时，filePathToBreakpointGroupNames 把test_user 的断点归入user组
• execve 触发 hook 时，hook 返回的组名（./test_user）与上面的（user）不一致
• 导致调试器切换到一个空组（N=0）

3. 修复了三个配置函数的组名一致性后，通知显示 N=3（3个用户断点），断点仍不生效——当前卡在这一步。

会议内容

1. 继续完成适配；
2. 完成后，想一想我做了些什么工作，怎么放入初赛中；

调试速查表：状态机变量含义

OSStates（状态）

值	名称	含义
0	kernel	当前在内核态，断点命中时检查是否为 border/hook
1	kernel_single_step_to_user	已命中 kernel→user border，正在逐指令单步，等待 PC 进入用户空间
2	user	当前在用户态，断点命中时检查是否为 user→kernel border
3	user_single_step_to_kernel	已命中 user→kernel border，正在逐指令单步，等待 PC 进入内核空间

OSEvents（事件）

值	名称	触发条件
0	STOPPED	GDB 报告程序停住（断点、单步结束、信号等）
1	AT_KERNEL	确认 PC 在内核地址空间
2	AT_KERNEL_TO_USER_BORDER	匹配到 kernel→user 方向的 border 断点
3	AT_USER	确认 PC 在用户地址空间
4	AT_USER_TO_KERNEL_BORDER	匹配到 user→kernel 方向的 border 断点

DebuggerActions（动作）

值	名称	做什么
0	check_if_kernel_yet	读 PC 寄存器，判断是否已进入内核空间（是→发 AT_KERNEL，否→继续单步）
1	check_if_user_yet	读 PC 寄存器，判断是否已进入用户空间（是→发 AT_USER，否→继续单步）
2	check_if_kernel_to_user_border_yet	检查当前停止位置是否匹配 kernel→user border
3	check_if_user_to_kernel_border_yet	读 PC，若在内核空间则检查是否为 user→kernel border，不是则切回 kernel 态
4	start_consecutive_single_steps	执行第一次单步（后续单步由 check_if_*_yet 循环驱动）
5	low_level_switch_breakpoint_group_to_high_level	从内核断点组切换到用户断点组（加载用户符号文件）
6	high_level_switch_breakpoint_group_to_low_level	从用户断点组切换回内核断点组（加载内核符号文件）
7	try_get_next_breakpoint_group_name	执行 hook 行为函数，获取下一个断点组名称（如进程名）
8	check_stop_in_kernel	内核态停止时：先检查 hook，再检查 border，都不是则暂停给用户

状态转换图

kernel
  │
  ├─ STOPPED ──→ kernel (check_stop_in_kernel)
  │                 ├─ 命中 hook → 执行 hook，continue，留在 kernel
  │                 ├─ 命中 border(→user) → AT_KERNEL_TO_USER_BORDER
  │                 └─ 都不是 → 暂停给用户，留在 kernel
  │
  └─ AT_KERNEL_TO_USER_BORDER ──→ kernel_single_step_to_user
                                      │
                                      ├─ STOPPED → check_if_user_yet
                                      │    ├─ PC 在用户空间 → AT_USER
                                      │    └─ PC 不在 → 继续单步，留在此状态
                                      │
                                      └─ AT_USER ──→ user（切换断点组到用户）

user
  │
  ├─ STOPPED ──→ check_if_user_to_kernel_border_yet
  │    ├─ PC 在内核 + 是 border → AT_USER_TO_KERNEL_BORDER
  │    ├─ PC 在内核 + 不是 border → AT_KERNEL（直接切回 kernel）
  │    ├─ PC 在用户 + 是 border → AT_USER_TO_KERNEL_BORDER（rCore 情况）
  │    └─ PC 在用户 + 不是 border → 暂停给用户，留在 user
  │
  ├─ AT_USER_TO_KERNEL_BORDER ──→ user_single_step_to_kernel（开始单步）
  │
  └─ AT_KERNEL ──→ kernel（StarryOS 情况：border 在内核空间，直接切换）

user_single_step_to_kernel
  │
  ├─ STOPPED → check_if_kernel_yet
  │    ├─ PC 在内核空间 → AT_KERNEL
  │    └─ PC 不在 → 继续单步，留在此状态
  │
  └─ AT_KERNEL ──→ kernel（切换断点组回内核）

调试时常用监视表达式

表达式	显示
OSStates[state.status]	当前状态名称
OSEvents[event.type]	当前事件名称
state.status	当前状态编号
event.type	当前事件编号
nextStateNode.target	目标状态编号
OSStates[nextStateNode.target]	目标状态名称
nextStateNode.actions	将要执行的 action 数组（每个的 type 对应上表）