嘿，这个问题我之前在分析二进制和源代码的时候都碰到过——逐行遍历指令找call/invoke的方法虽然直观，但在复杂场景下效率低还容易漏判，给你分享几个更优的实现思路：

1. 利用符号表或调试信息直接定位 #

如果你的目标文件带有符号表（比如ELF的.symtab、PE的导出/导入表）或者调试信息（比如PDB、DWARF），完全不用手动扫指令：

• 先通过符号表定位Function A和Function B的内存地址；
• 直接查询文件的调用关系元数据（比如ELF的重定位表、调试信息里的函数调用树），就能快速确认A是否调用了B。
  这种方法的优势是速度极快，尤其是大型项目里，不用遍历成千上万条指令。

2. 借助成熟静态分析工具/库 #

别自己造轮子，用现成的工具能省超多事：

• 二进制分析：用Ghidra或者Binary Ninja的脚本API，直接获取Function A的函数对象，调用内置方法（比如Ghidra的getCalls()）就能拿到所有被调用的函数列表，再判断是否包含B；也可以用radare2的命令af分析函数后，用agC查看调用关系。
• 源代码分析：如果有源码，用Clang AST遍历或者Pycparser这类库，解析出抽象语法树后，直接定位Function A的节点，遍历它的调用表达式匹配B的名字，准确率远高于指令扫描（不会被编译器优化的指令混淆）。

3. 针对间接调用的优化处理 #

如果场景中存在函数指针调用这类间接调用，单纯扫call指令很容易漏判，这时候可以结合数据流分析：

• 追踪Function A中所有函数指针的赋值来源，检查是否有指向Function B的路径；
• 对于动态链接的函数，查看PLT（过程链接表）条目，确认A是否通过PLT间接调用了B。

4. 预构建全局调用关系图 #

如果需要多次检查不同函数的调用关系，建议先一次性构建整个程序的调用关系图（Call Graph）：

• 用工具比如cflow（针对C代码）、CodeQL（支持多语言）或者静态分析库生成全局调用图；
• 后续每次查询只需要在图中检查A到B是否存在直接调用边，查询速度几乎是即时的。

对比你的原始方案：逐行扫指令适合小片段代码或无额外元信息的场景，但在复杂程序中不仅效率低，还容易漏掉间接调用、编译器优化后的特殊指令。上面这些方法要么利用已有元信息减少工作量，要么借助成熟工具处理边界情况，准确率和效率都提升明显。

内容的提问来源于stack exchange，提问作者mikasa