ARD 开发日志

Appearance

ARD调试K3工作 ​

1. StarryOS 启动性能优化 ​

问题：原Starryos启动调试时间消耗太大。

最初使用的 StarryOS 实验环境启动耗时较长，从 Welcome 到进入 Shell 平均需要约 264 秒，完整启动时间约300秒

为解决这一问题，更换为经过改造的新starryOS分支建立独立工作区，重新编译包含 DWARF 调试信息的 ELF，并适配 K3 原有固件和 UFS 启动流程。github链接：https://github.com/Oveln/tgoskits/tree/feat/k3-board-support

经过六轮测试，新版本从 Welcome 到 Shell 的中位耗时缩短至 21.50 秒，相比原派生实验镜像减少约 242.84 秒（91.87%），该阶段启动速度提升约 12.29 倍。正式工作区重新编译后的镜像也完成了真板启动验证，耗时约 21.51 秒。

2. ARD 真板调试验证 ​

在新的 StarryOS 环境下，成功完成 OpenOCD、GDB 和 ARD Debug Adapter 连接，Rust 源码断点能够正常命中。

同时验证了 ARD 的 RuntimeEvent、History、Observer Tree 和 Snapshot 功能，成功观察到 sleep_until → TimerFuture::poll 异步运行关系。

改进后显著减少了进入 Shell 前的等待时间与 ARD 调试时间。将 ARD 原有的测试示例改为新测试用例，同时完成了测试配置、工作区校验器和相关文档更新，支持通过环境变量指定外部 StarryOS 工作区。

《Back to the Future: Omniscient Debugging》-全知调试 ​

1. 问题 ​

Bug产生的原因通常在程序出现异常之前 原来程序调试方法有两种:

日志调试 ​

通过提前插入日志记录程序运行过程。

它可以保留程序历史执行信息。

但是需要提前修改代码。并且日志输出信息太多，后续人工分析困难。

断点调试 ​

如 GDB，通过暂停程序详细观察当前状态。

但是它只能看到当前执行位置，对于之前发生了什么通常无法恢复。开发人员需要不断重新运行程序，通过调整断点逐渐缩小范围。

怎样让开发者能够高效的回到过去，找到导致当前错误的事件？

2. 提出方法 ​

论文提出 Omniscient Debugging（全知调试），核心思想是：

记录程序完整执行历史，并允许开发者像查看录像一样，在执行历史中前后导航。

它结合了两种调试方式的特点：

  • 日志调试：保存过去发生的事情；
  • 断点调试：交互查看程序状态。

因此可以支持：

  • 向前执行；
  • 向后回溯；
  • 根据因果关系寻找错误来源。

3. 系统实现：TOD ​

作者实现了一个 Java 全知调试器：Trace-Oriented Debugger（TOD）。

核心目标：查询和导航历史事件 TOD四阶段

4. 论文解决的关键问题 ​

全知调试主要面临三个挑战，作者对此进行了解决。

TOD四阶段

《Lightweight User-Space Record And Replay》-调试的记录与重播 ​

1. 问题 ​

在程序调试过程中，有些 Bug 很难稳定复现，比如多线程竞争、异步信号或偶发错误。传统 GDB 调试通常需要反复运行程序，但每次执行过程可能不一样，因此很难准确找到错误原因。

分析 ​

方案1：通过整个虚拟机记录，但是记录信息太多，过于笨重

方案2：修改内核，会导致部署困难，普通用户不能直接使用。

方案3：代码插桩，需要修改/监控大量代码，导致性能下降

2. 提出方法 ​

作者认为，CPU 执行的大部分普通计算是确定性的，但是以下事情可能不同：

  • 系统调用返回的数据；
  • 多线程执行顺序；
  • 信号在什么位置到达；
  • 某些非确定性 CPU 指令的结果。

因此rr 选择用户空间与 Linux 内核之间的接口作为主要记录边界，通过控制不确定的变量，追求准确的记录并回放程序。 RR 架构

为了应对几个关键问题，系统主要采用三个技术机制。

RR 三项机制

ARD调试器与async-debug调试器架构区分 ​

真正的区别主要在信息如何采集、保存、验证以及最终展示

  • 旧版研究如何观察并恢复异步执行路径的问题；
  • 新版进一步研究如何持续的保留运行历史和建立关系，从而对历史与当前状态展示的问题。

主要架构如下： 架构对比

由于异步函数在执行过程中调用栈不连续。并且存在一个函数多次poll不同函数的情况

  • 快照累计版本能够观察到某些函数的执行，但是完整调用链依赖停止点 Snapshot 累计，未能将其保留在调用树中；
  • 新版通过后端运行事件积累，可以在没有中途 Snapshot 的情况下保留相应执行信息 下一步实验方向：验证旧版快照累计是否遗漏已观测的异步执行信息，以及新版后端 History 能否有效保留这些历史。