[Soot-list] instrumenting with soot class by class

[Eric Bodden]

Hello.

You can reset everything by calling G.reset(). However might it not be
easier for your purpose to just give Soot multiple files on the
command line instead of just one at a time?

Eric



2008/4/22 David Vollmar <kavika at the-dave.com>:
> All,
> I am trying to solve my problem now in a different manner: I can determine
> which classes I want to instrument, so I just will use soot to instrument
> classes one at a time in a very targeted fashion. The problem that I am
> running into is one of performance: Starting a new JVM for each class that I
> want to instrument becomes very expensive, so I would like to reuse the same
> JVM for instrumenting different classes. This approach works fine for the
> first class I try to instrument, but on the next pass, I am getting this
> stack trace:
>    [java] Exception in thread "main" java.lang.NullPointerException
>      [java] at soot.SootMethod.getBodyFromMethodSource(SootMethod.java:81)
>      [java] at soot.SootMethod.retrieveActiveBody(SootMethod.java:320)
>      [java] at soot.PackManager.retrieveAllBodies(PackManager.java:863)
>      [java] at soot.PackManager.runPacks(PackManager.java:323)
>      [java] at soot.Main.run(Main.java:203)
>
> I am guessing I need to somehow clear out the static variables in Soot, but
> I don't know how. Could someone please point me in the right direction?
> Thanks!
>
> ==================================================================================
> My instrumentation class looks something like this:
>
> public class MyInstrumenter extends BodyTransformer {
>
>
>  protected static MyInstrumenter instance = new MyInstrumenter();
>
>  protected MyInstrumenter() {
>  }
>
>  public static MyInstrumenter v() {
>  return instance;
>  }
>
>  protected void internalTransform(Body body, String pn, Map map) {
>   .....
>  }
>
>  public void setup() {
>
>  Scene.v().loadClassAndSupport("com.foo.bar.Call");
>  PackManager.v().getPack("jtp").add(
>  new Transform("jtp.instrumenter", MyInstrumenter.v()));
>
>  }
>
>  public void instrumentClass(String aClassName) {
>  String [] args = new String [] {aClassName};
>  soot.Main.main(args);
>  }
> }
> ==========================================================================
>
>
> On Apr 18, 2008, at 1:44 PM, Richard L. Halpert wrote:
> I recall someone asking about this type of use on the Soot list in the past.
> It might be useful to have a mechanism inside Soot to decide if a class
> should be written to file or not... for example if the decision on whether
> or not to transform a class needs to be determined by analyzing the class.
> Perhaps...
>
> -Rich
>
> On Fri, Apr 18, 2008 at 12:30 PM, Eric Bodden <eric.bodden at mail.mcgill.ca>
> wrote:
> >
> > >  I have contemplated that approach, yet I would find it much more
> elegant if
> > > Soot would offer a feature that would take care of this particular
> issue.
> > >  I am guessing that more people would be interested in this particular
> > > performance improvement.
> >
> > I am not sure. My guess is that most people use Soot for whole program
> > analysis and not on a file-by-file basis. But nevertheless there may
> > be some people who have use cases similar to yours.
> >
> >
> > >  So I am contemplating digging into the internals of Soot in order to
> see
> > > whether I can implement this feature.
> > >  What do you think?
> >
> > Sure, give it a try and let us know how it works. Depending on
> > somebody's Ant skills it's probably not harder than writing an Ant
> > script ;-)
> >
> >
> >
> >
> > Eric
> >
> > --
> > Eric Bodden
> > Sable Research Group
> > McGill University, Montréal, Canada
> > _______________________________________________
> > Soot-list mailing list
> > Soot-list at sable.mcgill.ca
> > http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
> >
>
>
>



-- 
Eric Bodden
Sable Research Group
McGill University, Montréal, Canada