拟解决的关键问题分析和目标

[Irissssaa]

本项目拟解决的关键问题分析

传统调试器基于同步执行模型设计，其核心是分析线程的函数调用栈。然而，Rust 的
async/await 语法将异步任务编译成一个复杂的状态机，由异步运行时在线程上进行调度。这
种编译和执行模型在传统调试器和 Rust 异步代码之间造成了巨大的语义鸿沟，导致了以下
两大类、五个核心关键问题：

（1）Rust 异步程序的调试盲区：异步函数状态与关系的不可见性

在传统调试器视角下，异步程序的状态和执行流是断裂和不透明的，开发者无法直观
地理解“单个异步任务执行到哪一步了”以及“这个异步任务是被谁 await 的”。

【问题一】Rust 异步函数的运行状态不透明

async 函数在编译后，其函数体成为一个包含多个状态（variant）的复杂结构体（即状
态机）。这种状态机在传统调试器中是“不透明”的，当 async 函数在某个.await 点暂停时，
其状态机只是切换到了一个新的 variant。在 GDB 中，开发者只能看到一个原始的结构体和
一个代表当前状态的数字，但是开发者并不能确定该数字表示的具体状态。

【问题二】传统调试器无法区分异步程序的逻辑执行流

传统调试器通过分析 OS 线程的物理调用栈来理解程序流程。然而，在异步程序中，一
个物理线程（执行者）会调度多个逻辑任务（协程），导致物理执行路径与异步逻辑执行流
存在差异。这体现在调用关系丢失：当一个异步函数 B await 另一个函数 A 时，物理调用栈
上并不会显示 B -> A 的调用关系。它显示的总是 Tokio Worker -> A，完全丢失了 B 这个逻
辑上的调用者信息。例如当使用 tokio::spawn 启动多个独立的后台任务时，它们都由同一个
线程池驱动。在 GDB 中，如果我们在一个被多个任务共用的函数上设置断点，通过 bt 打印
出的物理调用栈看起来是完全一样的（都是由 Tokio Worker 调用），从而无法区分当前是哪
个逻辑任务在执行。这是异步程序调试的根本困难。

【问题三】运行时调度的“黑盒”特性

Rust 没有官方运行时，社区驱动的 tokio、async-std 等运行时各自实现了复杂的任务调
度器。这些调度器决定了哪个 Future 在何时何地被哪个工作线程 poll。由于缺少统一的状
态暴露接口，开发者无法从外部探知一个任务为何被挂起、何时被唤醒，整个异步运行时
如同一个“黑盒”，增加了问题定位的难度。

（2）现有异步调试工具普遍存在通用性和实用性不足的问题

针对上述问题，社区已有一些探索，但普遍存在通用性和实用性不足的问题。

【问题四】调试工具与运行时的强耦合导致通用性低

现有的 Rust 异步调试方案大多与特定的平台或运行时深度绑定。例如，tokio-console 功
能强大，但它强依赖于 tokio 运行时并且需要源代码级的插桩；lildb 则针对特定的 lilos 操作
系统。这导致开发者无法拥有一个跨运行时的通用异步调试解决方案。

【问题五】缺乏灵活、低开销的按需追踪能力

异步程序，对性能高度敏感。全面的动态插桩3会带来不可忽视的性能开销，在生产环
境或性能测试中是不可接受的。现有工具缺少一种机制，让开发者能够精确地、动态地指
定追踪范围（即“白名单”功能），在不影响整体性能的前提下，对感兴趣的关键异步任务
进行调试。

项目目标

为解决上述关键问题，本项目旨在设计并实现一个基于 GDB 的白名单动态函数插桩跟
踪框架，具体实现目标如下：

目标 1：实现异步代码的静态依赖关系解析

这是整个框架的数据基础，旨在解决【问题一】和【问题二】中的关系挖掘困难。我们
将开发一个离线的静态分析工具，通过深度解析 DWARF 调试信息，识别出 Future 状态机
结构。通过递归分析状态机成员变量的 DW_AT_type 等关键字段，我们将精确地提取出所
有 Future 之间的依赖关系。此目标将产出两种核心的结构化数据：

• 一份机器可读的“异步调用依赖图谱”（JSON 格式），为后续的动态追踪提供结构化
  数据支持。
• 一份人类可读的“静态调用关系图”（Graphviz .dot 格式），帮助开发者直观理解代码
  的组织结构。

目标 2：实现运行时异步调用栈重建与“白名单”式追踪

这是框架的核心运行时功能，旨在解决【问题一】至【问题五】。我们将基于 GDB 这一
最通用的调试器，利用其 Python API 构建一个独立于任何特定 Rust 运行时的追踪工具。它
实现了三大创新亮点：

• 逻辑调用栈构建：传统 GDB 只能看到物理的 poll 调用，无法体现 await 关系。我们
  的框架通过结合目标 1 的静态依赖图谱，在运行时实时地将物理 poll 事件翻译为逻辑
  await 关系，从而重建出 main -> FutureA -> FutureB 这样符合开发者直觉的异步调用
  栈。
• “白名单”式按需追踪：为解决性能问题，用户可通过配置文件 (poll_map.json) 指定少
  数感兴趣的 async 函数作为起点。框架将利用依赖图谱，自动地扩展出与起点相关的
  所有上游和下游 Future，并仅对这个最小化的“异步任务子图”进行动态插桩，实现
  了低开销的精细化调试。
• 可扩展的数据采集 (模块化 Tracer)：除了默认的回溯追踪器，开发者可以轻松编写和
  注册自定义的 Tracer，用于采集特定信息，如函数参数、返回值、局部变量，甚至是
  特定于运行时的内部状态（如 tokio::task::Id）。这使得框架不仅是一个调用栈分析器，
  更是一个通用的异步行为数据采集平台。

目标 3：实现多维度的异步行为可视化分析

该目标旨在将采集到的原始数据转化为直观的、可交互的洞察，帮助开发者快速定位
问题。我们将实现两种互补的可视化方案：

• 动态性能可视化 (异步火焰图)：在运行时，我们的 Tracer 将采集每个 poll 函数调用
  的高精度时间戳和持续时间。这些数据将被处理并导出为 Chrome Trace Event 格式的
  JSON 文件。开发者可将此文件导入 Perfetto 或 chrome://tracing 等标准工具，生成交互
  式的“异步火焰图”。与传统火焰图不同，它以异步任务为中心，能够精确展示各个
  async fn 在不同线程上的执行时间、调度顺序和性能瓶颈（热点函数），为性能优化提
  供关键依据。
• 静态结构可视化 (依赖关系图)：如目标 1 所述，静态分析阶段将直接生成 Graphviz .dot
  格式的依赖图文件。开发者可使用 dot 或 xdot 等工具将其渲染成清晰的 await 关系图，
  用于代码审查、架构理解，直观地展示异步代码的组织结构。

总结来说，目标 1 是构建框架的数据基石，负责从静态代码中提取结构信息。目标 2 是
核心的交互式调试引擎，负责在运行时构建逻辑调用栈并提供按需追踪能力。而目标 3 则
是高级分析层，通过动静结合的可视化手段，将复杂的异步行为转化为开发者可理解的性
能和结构洞察。

[Irissssaa]

老师的意见：

现在写的这个三层结构已经不能同时表示出上面目标的两个不同功能。需要重新整理和扩充整个方案的逻辑思路，表示出以下逻辑：

1. 通过静态分析编译产物（是否需要加debug选项等）获得多组异步函数依赖关系（表现为多个依赖树组成的森林，可以用一个相对复杂一点的代码分析出对应的图放在这）（1、采用的什么方法，存在什么问题需要解决？2*、异步函数调用同步函数的情况如何进行分析）；
2. 将需要跟踪调试的异步函数列入白名单（白名单以什么形式存在，有什么过程？针对两个不同功能的白名单有什么区别？针对断点调试+异步调用栈的白名单是如何进行处理的？）；
3. 在GDB中增加特殊断点形式打在需要跟踪的函数入口和出口处（为什么要这样？），此特殊断点触发时进行代码插桩（我们的插桩并不是传统理解的进行代码注入，而是利用GDB的机制在断点后调用特殊的脚本，这个是需要进行解释的），即调用gdb脚本处理函数调用以及其他功能（不同的tracer是否就在这里进行体现？）；
4. 接下来是两个不同功能的实现，一个是让程序持续运行并将函数调用数据输出（通过什么形式进行输出？）到火焰图进行绘图（做了什么特殊的处理？）；二是断点后显示区分了异步执行流的调用栈（采用了什么方法，和已有的gdb调用栈有什么异同等）。