[Soot-list] Callgraph generation with Paddle

[Eric Bodden]

Hello.

I would recommend using a SceneTransformer, similar to:

public static void main(String[] args) {
  PackManager.v().getPack("wjtp").add(
    new Transform("wjtp.myTransform", new SceneTransformer() {
      protected void internalTransform(String phase, Map options) {
        Scene.v().getCallGraph(); //return paddle call graph
        //do your stuff here
      }
    }));
  soot.Main.main(args);
}

Then you only need to provide the right phase option on the command
line to this main class.

Eric

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



On 22 April 2010 16:14, François GOICHON <francois.goichon at insa-lyon.fr> wrote:
> Dear all,
>
> I want to (at least I have to..) implement a crafted points-to analysis
> for Java components. I actually have to implement a different points-to
> sets propagation algorithm.
> Therefore, I try to build a context-sensitive callgraph with Paddle,
> then I'll try to iterate over it or at least over the points-to sets to
> do my own stuff. I have been trying for some time now to construct a
> callgraph with Paddle, but I don't think I am doing it the right way so
> I am getting to you..
>
> I am using what I understood from the survivor guide for now:
>
>    private static SootClass loadClass(String name, boolean main) {
>        SootClass sClass = Scene.v().loadClassAndSupport(name);
>        sClass.setApplicationClass();
>        if (main) {
>            Scene.v().setMainClass(sClass);
>        }
>        return sClass;
>    }
>
>    private static void main(String[] args) {
>       Options.v().set_keep_line_number(true);
>       Options.v().setPhaseOption("cg", "verbose:true");
>       Options.v().set_full_resolver(true);
>       Options.v().allow_phantom_refs();
>
>       loadClass("DummyClass",false);
>       loadClass("MainClass",true);
>
>       Scene.v().loadNecessaryClasses();
>
>       // setting options HashMap
>
>       PaddleTransformer pt = new PaddleTransformer();
>       PaddleOptions paddle_opt = new PaddleOptions(opt);
>       pt.setup(paddle_opt);
>       pt.solve(paddle_opt);
>       //Verifying Scene.v().getContextSensitiveCallGraph();
>
>  }
>
> For this first run I tried with a simple options hashmap, quite the same
> that the one in the survivor guide (1cfa, on the fly callgraph, no heap
> abstract with buddy as bdd lib).
> DummyClass is quite simple (5 lines) and has only two imports: ArrayList
> and Iterator from java.util. The MainClass just calls a DummyClass
> object's method.
>
> Because of the apparent simplicity of this application, I am astonished
> that there are roughly 2150 classes loaded in the Soot Scene, doesn't it
> seem a lot ? Anyway, I start the analysis, which takes some minutes and
> terminates with a segfault inside libjeddbuddy (during pt.solve()),
> because I am running out of memory I suppose. I provided -Xmx512m
> -Xss256m as vm arguments.
> So my questions are:
>  - is it possible not to load all this classes, most of them being
> certainly loaded from unrealizable paths for my application (I actually
> tried not to use the full resolver option but then I add to add hundreds
> of addBasicClass(..., SIGNATURE|BODIES) and it was giving the same
> result anyway) ? Or to let Paddle dynamically load the needed classes
> when it encounters them ?
> - do I really need more memory for such a small program ??
>  - is there an easier way to build a context-sensitive callgraph with
> paddle (I am actually not sure what is going on within
> PaddleScene.solve()) ?
> I tried some different solutions from different existing applications
> using paddle without success.. I am quite lost and any hint or remark
> would be of great help for me.
> Thanks,
>
> François Goichon
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>