【开发日志】第十七周（2025.07.10）

[Irissssaa]

工作内容

1. 完善获取异步函数调用栈的功能

思路：用返回值类型获取更完整的 poll 函数和闭包列表，future 白名单功能

• **背景：**之前我们采用关键词过滤的方法从符号表中获得poll函数列表，然后使用 GDB 在这些函数上插桩，来获取异步函数调用栈；

• 遇到的问题：

  • 在完成初步版本后，我们考虑到这个方案理论上不稳妥，会导致异步函数调用栈仍然不够完整，因为要么过滤规则过于宽松，把无关的函数判断为poll函数，要么规则过于严格，将poll函数排除在列表之外，并且可能漏掉：匿名Future、动态生成的异步块（尽管在简单测试用例中这种情况不会出现）
  • 为了解决这个问题，我们尝试通过抓取异步运行时的信息获取task列表，其中包含着完整的future列表，但是由于编译优化的原因，GDB无法正确解析出future对应的poll函数位置（future结构体的内存布局中），在尝试后我们决定放弃这个做法。

• 思路动机：

  • 获取不到完整且正确的poll函数列表的主要原因是，创建一个poll函数的方式有很多种（例如impl future、async fn），每种创建方式生成的编译产物都是不同的，因此，解析这些编译产物的工作量比较大；
  • 但是，不管poll函数是以哪种方式创建的，它的返回值都一定是core::task::poll::Poll 类型；
  • 而且，几乎不存在非 poll 函数的返回值是 core::task::poll::Poll 的情况，因为这么做没有意义，就算真有这种情况我们也可以用白名单过滤掉；
  • 另外，这种跟踪方案就与线程无关，所以tokio task 调度到其他thread的情况也能应付；

• 实现（简单来说就是利用GDB的类型解析功能去获取到完整的poll函数和闭包）

  note：本质上这里所说的poll函数、闭包都属于poll函数，区分他们的原因是闭包future隐藏实现细节，生成匿名结构，和前者有区别，后面会具体提到。

  1. 用GDB解析符号表，列出所有函数；

  2. 用GDB的类型解析功能解析出这些函数的返回值；

  3. 过滤出返回值是core::task::poll::Poll类型的函数（包括poll函数和闭包）；

  4. 从白名单中过滤出需要跟踪的poll函数；

  5. 解析这些函数对应的future。考虑到future trait的定义一定是trait future里面一定有poll方法，解析方法是：函数名字一定是::为分割，删除最后一个元素。

     （note：原本打算在这些函数触发时，解析他们的self参数，由于self参数指向这个poll函数对应的future，这样获得的future名一定是最准确的，但是由于以下原因放弃了这个做法：

     a. 闭包没有self这个参数，只有_task_context 变量；

     b. 在调试前获取不到这些信息，导致无法实现白名单功能；）

  6. 在之前解析出的future依赖图中（注意是 future 类型的依赖关系，不是 future 变量的依赖关系），查找出和这个future有关联的所有future；

  7. 反过来解析出关联future对应的poll函数，对这些函数进行插桩，从而获得future的调用栈

     （疑问：运行时调用深层poll函数之前一定会调用浅层poll吗？还是说运行时可以在不调用浅层poll的情况下调用深层poll？这两种情况对应不同的调用栈生成方法）