测试总结 1

[Irissssaa]

测试总结

• 以下测试总结：

  总的来说，我们工具的能力边界可以用一句话来概括：

  它能够成功追踪所有由编译器生成的、使用具体类型 (Concrete Types) 的异步代码，因为这类代码会产生可预测的、结构化的 DWARF 信息。但当代码中出现手动实现、类型擦除 (dyn Trait) 或某些极端编译器优化时，这种可预测的结构被打破，工具便会失效。

  下面是详细的分类：

  ✅ 可以成功追踪的 poll 函数

  覆盖了绝大多数日常的 async/await 用法。

  1. 标准 async fn
     • 例子: async fn standard_async_fn() -> i32 { ... }
     • 原因: 这是最基本的情况。编译器会生成具有 {async_fn#0} (poll 函数) 和 {async_fn_env#0} (Future 状态机) 这种清晰、可预测的“兄弟节点” DWARF 结构。我们的脚本正是为此设计的。
  2. async 块
     • 例子: async { ... }
     • 原因: 与 async fn 类似，编译器会生成 {async_block#0} 和 {async_block_env#0} 的兄弟节点，同样能被我们的脚本正确识别和关联。
  3. 嵌套的异步函数调用
     • 例子: nested_async_fn 中 await 了 standard_async_fn 和 async_block。
     • 原因: 依赖扩展功能 (start-async-debug 的第 3 步) 是这个工具的核心优势。只要起点是一个可追踪的 Future，它就能利用 async_dependencies.json 这份“地图”，自动找到并插桩整个调用链上的所有可追踪的 poll 函数。
  4. 带泛型和生命周期的 async fn
     • 例子: generic_async_fn<T>(...), lifetime_async_fn<'a>(...)
     • 原因: 只要不涉及类型擦除，泛型和生命周期通常只是在类型名称上有所体现 (...<i32>)，并不会改变 poll/Future 兄弟节点的底层 DWARF 结构。我们的脚本能够正确处理这些名称。
  5. impl 块中的 async fn
     • 例子: impl MyStruct { async fn impl_async_fn(&self) { ... } }
     • 原因: 这种 async fn 同样遵循标准的编译器生成模式，会产生可预测的 {impl#...} 命名空间，并在其下生成可被关联的 poll 函数和 Future 结构体。

  ---

  ❌ 无法 成功追踪的 poll 函数

  这些情况暴露了工具的设计边界。

  1. 手动实现的 Future (impl Future for ...)

     • 例子: impl Future for ManualFuture { fn poll(...) }
     • 根本原因: DWARF 结构和命名约定完全不同。
       • poll 函数是 Future 结构体的“孙子”节点，而非“兄弟”。
       • poll 函数就叫 poll，Future 结构体是自定义名 ManualFuture，两者名字之间没有程序化的关联。我们为解决此问题而设计的“self 参数分析”法也因 DWARF 结构过于复杂而失败。

  2. 返回 Box<dyn Future> 的函数

     • 例子: fn boxed_future() -> Pin<Box<dyn Future<...>>> { ... }
     • 根本原因: 类型擦除 (Type Erasure)。
       • dyn Future 这个 Trait 对象向外界隐藏了内部 async 块的具体类型。
       • 这导致编译器生成的 DWARF 信息中，poll 函数和 Future 状态机之间的“兄弟”关联被打破或变得不可预测，我们的脚本无法再将它们稳定地链接起来。

  3. 使用了 #[async_trait] 的函数

     • 例子: #[async_trait] async fn my_method() { ... }
     • 根本原因: 与 Box<dyn Future> 完全相同。#[async_trait] 宏的本质就是将 async fn 自动重写成一个返回 Pin<Box<dyn Future<...>>> 的普通函数，因此它继承了类型擦除带来的所有问题。

  4. 被完全内联优化的 async fn

     • 例子: 最初版本的 combinators_async_fn。
     • 根本原因: 编译器优化。
       • 如果一个 async 函数的逻辑过于简单，从不真正挂起（即从不返回 Poll::Pending），编译器可能会将其整个函数体“内联”到调用处。
       • 这导致对应的 poll 函数虽然存在于符号表中，但没有任何 call 指令会去调用它，因此设置在它上面的断点永远不会被触发。

  5. 补充总结：

     

[Irissssaa]

补充总结中最后一个想法不正确：

• 因为我们的工具是要跟踪内核的，内核中有很多函数也是很复杂的，还是需要尽量实现底层的函数追踪