[Soot-list] Type inference in Soot for Java polymorphism?

Bernhard Berger berber at tzi.de
Wed Jan 23 01:03:12 EST 2013 

Hi Yi,

you cannot turn of the jb phase because it normalizes the jimple code generated by the front end. AFAIR you can disable all other packs. If you are interested in getting the results of the points-to analysis you have to run at least jb and cg.

Bernhard

Am 23.01.2013 um 06:07 schrieb Yi Lin <qinsoon at gmail.com>:

> Turning off jb pack or any subphase in jb (I tried a few) will cause a 
> failure during building call graph. Guess there is subtle dependence 
> between different phases.
> 
> On 23/01/13 14:43 , Tony Yan wrote:
>> Hi,
>> 
>> If you really want the "original" (whatever that means) Jimple code,
>> you can try to disable the transformation/optimization in the jb pack.
>> See <http://www.sable.mcgill.ca/soot/tutorial/phase/phase.html#SECTION00020000000000000000>
>> for those options.
>> 
>> Also, if you haven't done so yet, look at this post
>> <http://www.bodden.de/2008/11/26/soot-packs/> to understand the packs
>> and phases in soot.
>> 
>> Thanks,
>> Tony
>> 
>> On Tue, Jan 22, 2013 at 7:51 PM, Yi Lin <qinsoon at gmail.com> wrote:
>>> Hi,
>>> 
>>> Thanks for all the help. I set options as you suggested, and also I exclude
>>> java library, and properly set application classes. Now the Soot run is
>>> really fast.
>>> 
>>> Then my problem is that I cannot retrieve Soot method body after the run. I
>>> didn't actually run Soot before. What I used to do was to use Soot to
>>> resolve classes, and retrieve method bodies. So I could get original jimple
>>> representation of the source (.java or .class) without any transformation or
>>> optimization.
>>> 
>>> I saw someone asked this on the mailing list before. The answer was that
>>> Soot may purge jimple body after its run. And I am not supposed to retrieve
>>> method body after the run; instead I should use BodyTransformer during the
>>> run to do whatever I want to.
>>> 
>>> So I am wondering:
>>> 1. Can I turn off those transformations or optimizations on jimple body (so
>>> the jimple representation stays the same as they are just generated from the
>>> source)?
>>> 2. In which phase I might be able to get the original jimple body?
>>> 3. Is SPARK points-to analysis based on the transformed jimple body? If so,
>>> the analysis results would make no sense on the original jimple body unless
>>> I am able to turn off the transformations.
>>> 
>>> 
>>> Thanks very much.
>>> 
>>> Regards,
>>> Yi
>>> 
>>> On 23/01/13 2:48 , Tony Yan wrote:
>>>> Hi Yi,
>>>> 
>>>> You need to move your parameter configuration out of the
>>>> `internalTransform' method to the `sootArgs' list. Also, remove the
>>>> call to SparkTransformer since it will have been called since you have
>>>> already enabled it with "-p cg.spark enabled:true".
>>>> 
>>>> As you might have already known, you can access the result of SPARK
>>>> with something like the following in your `internalTransform':
>>>> 
>>>>     PAG pag = (PAG) Scene.v().getCallGraph();
>>>>     pag.reachingObjects(local) ;
>>>>     ... // and so on
>>>> 
>>>> You can reference the document of PAG here:
>>>> http://www.sable.mcgill.ca/soot/doc/soot/jimple/spark/pag/PAG.html
>>>> 
>>>> To avoid expensive transformations:
>>>>     1. Put "-f n" in sootArgs to disable output generation
>>>>     2. Add your SceneTransformer to wjtp instead of wjop.
>>>>     3. Put "System.exit(0)" at the end of your `internalTransform'
>>>> 
>>>> When you are done with this, you will have result of SPARK ready at
>>>> entry of `internalTransform', and you get to do whatever analysis you
>>>> want in `internalTransform' and exit from the whole program
>>>> afterwards.
>>>> 
>>>> Thanks,
>>>> Tony
>>>> 
>>>> On Tue, Jan 22, 2013 at 3:05 AM, Yi Lin <qinsoon at gmail.com> wrote:
>>>>> Thanks very much. That is very helpful.
>>>>> 
>>>>> I read some documents about SPARK. However I am having some problems
>>>>> using
>>>>> SPARK with my code.
>>>>> 
>>>>> 1. I used to only use Soot to resolve classes, and I didn't run any
>>>>> transformation or optimizations by Soot. However, it seems if I want
>>>>> points-to analysis result from SPARK, I would have to run
>>>>> soot.Main.main(),
>>>>> which involves all transformations and optimizations. This not only takes
>>>>> a
>>>>> quite long time, but also is undesirable. How can I very 'cleanly' get
>>>>> the
>>>>> points-to analysis from SPARK? (I will attach the code I am running with
>>>>> at
>>>>> the end of this email, which was found from the mail-list archives)
>>>>> 
>>>>> 2. After I added those code to run SPARK, I am not able to retrieve any
>>>>> method body. The pseudo-code for my program is like,
>>>>> 
>>>>>      (1)initSootOptions();
>>>>>      (2)resolveClassesThatINeed();
>>>>>      (3)walkThroughThoseClasses();
>>>>> 
>>>>> But after I add 'runSPARK()' after (1) or (2), in (3) it failed to get
>>>>> method body.
>>>>> 
>>>>> java.lang.NullPointerException
>>>>>      at soot.SootMethod.getBodyFromMethodSource(SootMethod.java:89)
>>>>>      at soot.SootMethod.retrieveActiveBody(SootMethod.java:322)
>>>>> 
>>>>> Sorry if those questions sound naive. I quickly went through Ondrej's
>>>>> SPARK
>>>>> thesis, I got Soot survivor guide with me, I searched through mail list.
>>>>> But
>>>>> I am still quite lost.
>>>>> 
>>>>> Thank you very much.
>>>>> 
>>>>> Regards,
>>>>> Yi
>>>>> 
>>>>> the code that I am running SPARK with:
>>>>> 
>>>>> runSPARK() {
>>>>>          List<String> sootArgs = new ArrayList<String>();
>>>>>          sootArgs.add("-W");
>>>>>          sootArgs.add("-p");
>>>>>          sootArgs.add("wjop");
>>>>>          sootArgs.add("enabled:true");
>>>>> 
>>>>>          //enable points-to analysis
>>>>>          sootArgs.add("-p");
>>>>>          sootArgs.add("cg");
>>>>>          sootArgs.add("enabled:true");
>>>>> 
>>>>>          //enable Spark
>>>>>          sootArgs.add("-p");
>>>>>          sootArgs.add("cg.spark");
>>>>>          sootArgs.add("enabled:true");
>>>>> 
>>>>>          PackManager.v().getPack("wjop").add(new
>>>>> Transform("wjop.mytrans",new
>>>>> SceneTransformer() {
>>>>>               protected void internalTransform(String phaseName, Map
>>>>> options)
>>>>> {
>>>>>                   System.out.println("SPARK pointer-to analysis...");
>>>>>                   HashMap map = new HashMap(options);
>>>>>                   //set the PointsToAnalysis with phase options
>>>>>                   map.put("verbose", "true");
>>>>>                   map.put("propagator", "worklist");
>>>>>                   map.put("simple-edges-bidirectional", "false");
>>>>>                   map.put("on-fly-cg", "true");
>>>>>                   map.put("set-impl", "hybrid");
>>>>>                   map.put("double-set-old", "hybrid");
>>>>>                   map.put("double-set-new", "hybrid");
>>>>>                   SparkTransformer.v().transform("",map);
>>>>>               }
>>>>>             }));
>>>>> 
>>>>>          soot.Main.main(sootArgs.toArray(new String[0]));
>>>>> }
>>>>> 
>>>>> 
>>>>> On 22/01/13 16:09 , Richard Xiao wrote:
>>>>> 
>>>>> Of course, try SPARK, the points-to analysis in soot. You will obtain a
>>>>> list
>>>>> of objects "cat" can point to. Compute the lowest common ancestor of the
>>>>> types of these pointed to objects, that's the answer.
>>>>> 
>>>>> 
>>>>> On Tue, Jan 22, 2013 at 10:56 AM, Yi Lin <qinsoon at gmail.com> wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> For example.
>>>>>> 
>>>>>> For Java code,
>>>>>>       Animal cat = new Cat();
>>>>>>       cat.speak();
>>>>>> 
>>>>>> Jimple code is like,
>>>>>> Locals:
>>>>>>       [Animal]cat
>>>>>>       [Cat]temp$0
>>>>>> Code:
>>>>>>       temp$0 = new Cat
>>>>>>       specialinvoke temp$0.<Cat: void <init>()>()
>>>>>>       cat = temp$0
>>>>>>       virtualinvoke cat.<Animal: void speak()>()
>>>>>> 
>>>>>> Is it possible for Soot to tell that the variable 'cat' actually holds a
>>>>>> 'Cat' object instead of an 'Animal'?
>>>>>> 
>>>>>> If not, is it possible for me to implement such analysis on Soot
>>>>>> framework (especially for inter-procedure cases)? Without using dynamic
>>>>>> loading in the Java code, and with whole program analysis turned on in
>>>>>> Soot, I assume it should be possible to do such type inference.
>>>>>> 
>>>>>> Any idea would be appreciated. Thank you very much.
>>>>>> 
>>>>>> Regards,
>>>>>> Yi
>>>>>> _______________________________________________
>>>>>> Soot-list mailing list
>>>>>> Soot-list at sable.mcgill.ca
>>>>>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Richard Xiao Xiao
>>>>> PhD Student @ CSE @ Hong Kong University of Science and Technology
>>>>> www.cse.ust.hk/~richardxx
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Soot-list mailing list
>>>>> Soot-list at sable.mcgill.ca
>>>>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>>>> 
>>>> 
> 
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list

More information about the Soot-list mailing list