开发者

Call graph of the whole application

开发者 https://www.devze.com 2022-12-18 06:21 出处:网络
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.

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.

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.

I have tried Soot so far. However, it is not able to handle ev开发者_开发技巧en 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

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


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.).

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 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.


JProfiler is a decent Java profiler which will generate the call graph as well as allows you to export it in XML format.

I have not used Soot , so I cannot comment on how JProfiler stands as compared to Soot, but expect JProfiler to require 2.5-3 times memory as compared to the application.


1.5 GB is not very much memory for a realistic call graphs. I guess Soot just gives you what you are asking for. Call graphs by other tools may be smaller, but then they will likely be incomplete.


Check out http://semmle.com/

I have used their tool when it was in beta. It builds a database of program information that you can programmatically query. The company is a startup and the product is no longer in beta though I cannot find anywhere on their site how to purchase it or how much it costs.

NDepend (http://www.ndepend.com/) is a similar tools for .NET that I have also used but I am not sure if one can access it programatically. XDepend (http://www.xdepend.com/) is their tool for Java, which I have not used.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号