[Soot-list] Type inference in Soot for Java polymorphism?
Yi Lin
qinsoon at gmail.com
Wed Jan 23 00:07:10 EST 2013
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
>>>>
>>>
More information about the Soot-list
mailing list