符号恢复的工具链与取舍

错误信息与日志格式串经常直接暴露函数用途，是最便宜的信息来源，前提是没被裁掉

工具解决的是「看得见」的问题，判断还是要靠人。

先说结论

工具要少而熟。

• 静态：看结构
• 动态：看数据
• 辅助：做批量
• 先用熟的描述问题
• 效率来自脚本

三类工具

按这个分工选：

函数序言与控制流图形状，比字符串更可靠地指示编译器类型与优化级别，字符串反而容易被混淆。

怎么选

错误信息与日志格式串经常直接暴露函数用途，是最便宜的信息来源，前提是没被裁掉。

先用最熟的那个把问题描述清楚，再换工具验证。

几个具体经验

下面这些是相对确定的细节：

• C++ 的 RTTI 与虚表结构能还原类层次关系，前提是编译时没有关掉 RTTI

别做的事

看到一个像 md5 的常量就把函数命名成 md5_update。

换工具不能代替思考，只会让你更晚发现问题。

一句提醒

符号恢复的目标是「读得下去」，不是「还原成源码」。

工具链稳定下来之后，效率提升来自脚本，不来自新工具。

还有几处容易忽略的

这些细节不影响入门，但影响你判断的准确度。

• 识别出库函数能消掉六成以上的符号，剩下的才是需要人读的业务逻辑，值得逐行看
• 命名要立刻回填到调用图里，否则第二天就忘了当初为什么叫这个名字
• 错误的命名比没有命名更糟，它会让后来的人顺着错误假设一直读下去，不确定就标成 func_sub_xxx
• 看到一个像 md5 的常量就把函数命名成 md5_update
• 只在大函数上花时间，忽略了小工具函数
• 改完名字不写备注，交接时全部推倒重来

工具是手脚，判断是脑子。