[Soot-list] Trying to build call graph from with a java program

[Eric Bodden]

Varun you should consult the tutorials:
http://www.sable.mcgill.ca/soot/tutorial/index.html

In particular, the survivor's guide: http://www.brics.dk/SootGuide/
Also, you can use the eclipse plugin to generate some code stubs for
you which you can build on:
http://www.bodden.de/2008/08/30/soot-eclipse-plugin-tutorial/

All the information you need is in there. When you use Soot correctly,
adding transformers and calling Soot's main method then the call graph
can simply be accessed using Scene.v().getCallGraph().

Hope that helps,
Eric


2009/9/2 vasrivastava at hssworld.com srivastava <varun0007 at gmail.com>:
> Hi Khilan,
>  My observations inline after trying out your suggestions.
>
> On Mon, Aug 31, 2009 at 4:22 AM, Khilan Gudka <khilan at doc.ic.ac.uk> wrote:
>>
>> Hi Varun,
>> From what I understand, you can get the "call graph" for a method by using the CallGraph.edgesOutOf(Unit) and CallGraph.edgesOutOf(MethodOrMethodContext) methods. These allow you to traverse the call graph, from a particular statement
>
>>>>Varun : CallGraph and TransitiveTargets methods are not static . So to call them I need a callgraph on first place I guess [Am i missing something ?]
>>
>> or method respectively. Furthermore, the class TransitiveTargets can be used to get all methods reachable from a method or statement. So, for what you are trying to do, you could potentially iterate through all the methods in a class using SootClass.getMethods() and then use the CallGraph.edgesOutOf methods or TransitiveTargets class to traverse the "call graph" from that specific method.
>> Alternatively, you could use the all-reachable:true flag to the cg phase (i.e. -p cg all-reachable:true). From the phase options documentation:
>
>>>>Varun : to get call grpah I am trying out --- HashMap opt = new HashMap();
> opt.put("verbose","true");
> opt.put("all-reachable","true");
>                                                  CHATransformer.v().transform("",opt);
>      But this is also failing with "couldn't find method main(*)" Exception.
>>
>> "Setting this option to true makes Soot consider all methods of application classes to be reachable, so call edges are generated for all of them."
>> Then you could iterate through the entry points (EntryPoints.v().all()) and then use the edgesOutOf methods or TransitiveTargets class as mentioned above).
>> Hope that helps
>> --
>> Khilan Gudka
>> PhD Student
>> Department of Computing
>> Imperial College
>> http://www.doc.ic.ac.uk/~khilan/
>> On 31 Aug 2009, at 03:38, vasrivastava at hssworld.com srivastava wrote:
>>
>> Hi Eric,
>>   I want to perform some analysis on different set of classes and then compare the results. The ideal thing for me to do is , create some application specific datastructure for each of the sets and then compare them inside my program.
>>  To achieve this, on the high level I am trying to follow the given algorithm
>> 1) Load a class from set A into soot using loadandsupport api
>> 2) Perform interprocess data flow analysis for each of the methods individually
>> 3) Perform same operation for a class of set B
>> 4) Compare results of set A and set B and then print out final results.
>> Now for this analysis I need to analyse all the public methods individually in interprocedural fashion [ as all the public methods can be called by any application outside the class]
>>   But right now I am not able to construct a call graph for each method individually, so that i can run my inter procedural dataflow analysis on that call graph.
>>  Please suggest me the right way to do this , as I guess I am on the wrong way :(.
>> Thanks
>> Varun
>>
>> On Sun, Aug 30, 2009 at 2:36 AM, Eric Bodden <bodden at st.informatik.tu-darmstadt.de> wrote:
>>>
>>> Hi.
>>>
>>> >  I am trying to build call graph for a class from a java program. I need to
>>> > take each method the class and build a call graph as if that method is the
>>> > main method. I haven't got any way of declaring any arbitrary method as
>>> > reachableMethod and continue call graph construction.
>>>
>>> From what you write, it seems like you would want to play around with
>>> the class EntryPoints. I don't understand why you are adding "main"
>>> methods to every class. How would that solve your problem? What
>>> exactly is the problem that your analysis should solve anyway?
>>>
>>> Eric
>>>
>>> --
>>> Eric Bodden
>>> Software Technology Group
>>> Technical University Darmstadt, Germany
>>
>> <ATT00002.txt>
>
>



-- 
Eric Bodden
Software Technology Group, Technische Universität Darmstadt, Germany
Tel: +49 6151 16-5478    Fax: +49 6151 16-5410
Mailing Address: S2|02 A209, Hochschulstraße 10, 64289 Darmstadt