[Soot-list] Type inference in Soot for Java polymorphism?
Tony Yan
yan at cse.ohio-state.edu
Tue Jan 22 22:43:25 EST 2013
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