用好工具

回到笨拙的 info inferiors 和 pmap

你们一定不会愿意用的

• 就像你不希望用汇编写代码
  • AskGPT: Can I print process memory maps inside gdb?
  • AskGPT: Can I visualize a process-internal data structure in gdb?
    • (GPT 没给我 “惊喜”，但我没有他那么好的记忆读取能力)
• 服气
  • 我十多年 RTFM 积累的经验，在 AI 面前一文不值

计算机系统公理

1. 机器永远是对的
   • (ICS PA/OS Labs: 怕是不用多说了)
2. 未测代码永远是错的
   • (ICS PA/OS Labs: 怕是不用多说了)
3. 让你感到不适的 tedious 工作，一定有办法提高效率
   • 推论：我们应该分辨出什么工作是 tedious 的

“三省吾身：滚去编程了吗？写测试用例了吗？回看自己的工作流程了吗？”

• AI 构建学习阶梯
• 在方方面面强迫我们三省吾身
• 人类文明进入新纪元

更进一步：连接两个世界

程序 = 计算机系统 = 状态机

• 调试器的本质是 “检查状态”
• 我们能不能用自己想要的方式去检查状态？
  • 例如，像 model checker 那样把一个链表绘制出来？
• AskGPT: How to use Python to parse and check/visualize C/C++ program state in GDB?
  • GPT-4 甚至给出了正确的文档 URL

然后我们就可以做任何事了

• TUI Window API
• 甚至，我们可以做另一个 debugging front-end
  • gdbgui

调试困难的根本原因

我们只能检查一个瞬间的状态

• Reverse debugging 的成本还是太高了
• 而且 time-travel 也很难操作
  • 如果我们能精简状态就好了！
  • 精简状态不就行了吗……

自己动手做工具

• 调试 thread-os

我们需要的：想象力

The UNIX Philosophy

• Keep it simple, stupid
• 把 gdb 状态导出 serialize 到文件/管道中
• 由另一个程序负责处理
  • 就像我们的 interactive state space explorer

assertions 也不一定要写在 C 代码里

• 导出的状态可以做任何 trace analysis