静态调用图分析可以破译哪些问题？
人们希望在程序上使用静态调用图分析来发现哪些问题？ FxCop 使用静态调用图分析，使用这种技术发现了什么问题？
http://msdn.microsoft.com/library/bb429476.aspx
http://en.wikipedia.org/wiki/Callgraph
抱歉我缺乏知识，我通过谷歌找到了一些信息，但担心它非常不完整。谢谢！
What issues would one hope to find using static call graph analysis on a program? FxCop uses static call graph analysis, what issues does it find using this technique?
http://msdn.microsoft.com/library/bb429476.aspx
http://en.wikipedia.org/wiki/Callgraph
Apologies for my lack of knowledge, I found some information via google, but fear that it is vastly incomplete. Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
调用图本身就是这样；不存在“错误”的调用图（除非您有禁止递归的样式检查）。
真正的问题是，要了解程序中某个点的代码可能如何出现问题，您通常需要了解该点的世界形状（哪些数据结构是实时的、它们可能包含哪些值、它们可能具有哪些关系）该代码点处于活动状态的时刻。调用图显示执行如何到达感兴趣的代码点，并且沿着该调用图路径的所有代码设置代码执行上下文。这使得静态分析器能够产生“上下文相关”分析，从而给出更准确的答案。
这就引出了第二个问题：如何获得准确的调用图？如果您从 A 直接调用 B，则很容易写下“A 调用 B”并感觉这是一个准确的调用图事实。但是，如果 A 通过间接指针进行调用（可以说虚拟方法调度吗？），突然间就不太清楚 A 到底调用了谁；你最终会得到 A-可能调用-B1，A-可能调用-B2，... A 实际调用哪一个实际上取决于 A 执行的上下文... 哎呀，您需要调用图来制造调用图。好消息是您从底部开始构建调用图：“我知道这肯定是真的，所以那肯定是真的”。在分析器无法弄清楚的地方，它通常会做出保守的猜测：（“所有这些调用都有可能，我不能排除它们”）。这种保守性是静态分析仪准确度的关键原因之一。
By itself the call-graph is just that; there are no "wrong" call graphs (unless you have a style check prohibiting recursion).
The real issue is that to understand how code at a point in the program might be problematic, you typically need to understand the shape of the world (what data structures are live, what values they might contain, what relationships they might have) at the moment where that code point is active. The call graph shows how execution can get to the code point of interest, and all the code along that call graph path sets the code execution context. This enables the static analyzer to produce a "context-sensitive" analysis, which gives much more accurate answers.
This leads to a second problem: how does one get an accurate call graph? If you have a direct call of B from A, it is easy to write down, "A calls B" and feel this is an accurate call-graph fact. But if A makes an call through an indirect pointer (can you say virtual method dispatch?) suddenly it isn't so clear exactly who A calls; you end up with A-might-call-B1, A-might-call-B2, ... Which one A actually calls in fact depends on the context in which A executes... oops, you need the call graph to manufacture the call graph. The sort of good news is that you build the call graph up from the bottom: "I know this is surely true, so that must be surely true". At places where the analzyer can't figure it out, it generally makes a conservative guess: ("All of these calls might be possible, I can't rule them out"). That conservatism is one of the key causes of the accuracy of your static analyzer.
这就是我发现的：
调用图用于检测与程序执行、违反建议准则以及可能的代码注入攻击有关的问题。
通过创建各个方法之间的调用关系图，可以很容易地看出某些方法在某些时候可能会出现问题，或者某些方法是如何调用的。当过程/函数可能违反诸如维持代码模块化之类的准则时，很容易看出。由于这些调用关系以及它们的结构，很容易看出恶意代码可能在某些点注入。通过这种方式，调用图为静态分析提供了上下文，从而产生更准确的结果。
由于 FxCop 使用静态调用图，因此它只能在一定程度上推测上述内容。
This is what I've found:
Call-graphs are used to detect issues in regards to program execution, violation of recommended guidelines, and possible code injection attacks.
By creating a graph of the calling relationships among various methods, it is easy to see where issues may arise at certain times when certain methods are called or how certain methods are called. It's easy to see when a procedure/function may be violating guidelines such as sustaining code modularity. It's easy to see where malicious code could possibly be injected at certain points because of those calling relationships, and how they are structured. In this way, call-graphs provide context to static analysis, producing more accurate results.
Since FxCop uses static call-graphs, it is only able to speculate on the above to a degree.