整个应用的调用图 [英] Call graph of the whole application

问题描述

有没有可以创建整个应用程序调用图的非玩具工具?我不是说只是通过逐个指向的方式来获取图片或绘制调用图.

Is there a non-toyish tool that can create a call graph of the whole application? I don't mean just getting a picture or drawing call graph by means of pointing method-by-method.

我需要一个可通过编程访问的调用图，即该工具应将其刷新到文本模式(例如 XML)的文件中，或在内存中构建调用图(这对于大型应用程序而言会出现问题).数据库中内置的调用图会很棒.

I need a call graph, which is accessible programmatically, i.e. the tool should flush it to a file in text mode (e.g. XML) or build the call graph in memory (which becomes problematic for large application). A call graph built in a DB would be great.

静态和动态调用图都需要；虽然静态的更有趣一点，但它被过度近似的事实是可以接受的.

Both static and dynamic call graphs are in demand; though static one is a little more interesting, the fact that it is overapproximated is acceptable.

到目前为止我已经尝试过 Soot.然而，它甚至不能处理像 FreeCol 这样的中等规模的项目(Java 源代码可用).Soot 耗尽了该项目的 1.5GB 内存，然后 JVM 崩溃，如下所述:http://www.sable.mcgill.ca/pipermail/soot-list/2008-July/001828.html

I have tried Soot so far. However, it is not able to handle even medium-size projects like FreeCol (java sources are available). Soot depletes 1.5GB of memory on that project, and then JVM crashes, as described here: http://www.sable.mcgill.ca/pipermail/soot-list/2008-July/001828.html

有人能推荐一个工具来生成调用图，如上所述吗?Java 或 .NET 语言都可以.

Could anyone suggest a tool to generate a call graph, as described above? Java or .NET languages are ok.

推荐答案

我们的 DMS 软件Reengineering Toolkit 可以为 C、Java 和 COBOL 构建全局调用图.这些被计算为内存中的数据结构，然后可以遍历以收集任意其他事实.(你可以将它导出到其他工具来遍历它，但是对于一个大的调用图，导出的时间和精力将支配分析它的时间，所以我们倾向于不导出它.YMMV.).

Our DMS Software Reengineering Toolkit can construct global call graphs for C, Java, and COBOL. These are computed as an in-memory data structure, and can then be walked to collect arbitrary other facts. (You could export it to some other tool to walk over it, but for a big call graph the time and effort to export would dominate the time to just analyze it, so we tend not to export it. YMMV.).

从CALL X(...)"抽象形式的语句中提取调用图信息相对容易，因为目标 X 就在调用站点的代码中.间接(虚拟或方法调用)的问题在于实际调用目标在调用站点的代码中并非微不足道，而是实际上分散在整个系统中，更糟糕的是，受运行时条件控制.在没有任何附加信息的情况下，调用图构造函数必须假设间接调用可以访问具有匹配签名的任何目标；这在图中引入了大量假阳性调用弧.

It is relatively easy to extract call-graph information from a statement of the abstract form of "CALL X(...)", because the target X is right there in the code at the call site. Indirect (virtual or method calls) are problematic in that the actual call targets are not trivially in the code at the call site, but in fact are scattered around the entire system and worse, controlled by runtime conditionals. In the absence of any additional information, a call graph constructor has to assume an indirect call can go to any target with a matching signature; this introduces lots of false-positive call arcs in the graph.

DMS 使用(保守的)全局指向分析作为调用图提取过程的一部分，以确定此类间接调用的去向，同时最大限度地减少误报.请参阅流分析和调用图，了解更多有关 DMS 可以提取的内容的示例，以及从包含 250,000 个函数的系统中提取的示例图.

DMS uses a (conservative) global points-to analysis as part of the call-graph extraction process, to determine where such indirect calls go, while minimizing false-positives. See Flow analysis and call graphs for more examples of what DMS can extract, and a sample graph extracted from a system of 250,000 functions.

这篇关于整个应用的调用图的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！