[Soot-list] Using soot within a javaagent

[Prashant Deva]

Ok, so result of my little experiment:

This code:

public static void main(String[] args)
{
Options.v().allow_phantom_refs();
SootClass sootClass = Scene.v().loadClass("com.chtest.Snippet",
SootClass.BODIES);

}

throws an exception:
java.lang.IllegalStateException: RefType java.lang.ArithmeticException not
loaded.

if i add the line:
Scene.v().loadNecessaryClasses();

then the exception is gone.

Here is the Snippet class:
public class Snippet
{
public int foo(int i, int j) {
    while (true) {
        try {
            while (i < j)
                i = j++ / i;
        } catch (RuntimeException re) {
            i = 10;
            continue;
        }
        break;
    }
    return j;
}
 }

Why is it that even after allowing phantom refs soot throws an exception
for a type not loaded?


Prashant


On Fri, Dec 30, 2011 at 2:31 AM, Eric Bodden <eric.bodden at ec-spride.de>wrote:

> Hello.
>
> >  Yes, I would very much like to work with you on restructuring soot to
> allow
> > it to work as a javaagent.
>
> Great. Then let's discuss what needs to be done.
>
> > As for resolution of dependencies, I dont require it and i guess anyone
> > using it as a java agent wont either.
>
> Things are not quite that simple. Soot uses some amount of typing
> information (and in particular the type hierarchy) to re-construct
> typed local variables from (untyped) stack locations. Hence, Soot
> usually does need some knowledge about the dependencies. Having said
> that, Soot's phantom-refs mechanism usually allows one to model
> dependencies as "empty phantom classes", which is often good enough.
> Those phantom classes do not carry any information about the actual
> type hierarchy but for things like local pointer analysis that may not
> actually matter.
>
> In a first step, you should probably try for a few example classes if
> Soot emits "reasonable" Jimple code when invoked on a simple class
> with phantom refs enabled, e.g.:
>
> soot -f J -cp . -allow-phantom-refs TestClass
>
> (where the current directory only contains TestClass.class/.java and
> nothing else)
>
> > If i am correct, this would require converting the bytecode to jimple and
> > for each method separately getting the 'points-to' data.
>
> The points-to analysis does not really work on an intra-procedural
> level but there are a LocalMustAliasAnalysis and
> LocalMustNotAliasAnalysis that should do the trick.
>
> > Any guidance on where to start restructing the codebase to achieve the
> > required and get rid of dependency resolution would be helpful and as per
> > the terms of lgpl i would be happy to share my results with you.
>
> Ok, assuming that the bytecode-to-Jimple conversion generally works
> reasonably correct on a single class (see above), I think one would
> then need to proceed as follows:
>
> Soot currently loads classes by name: you provide a name and Soot
> looks for that class on its classpath. Lookup is performed by passing
> the class name to soot.SourceLocator.getClassSource(String), which
> returns a classSource, i.e., an actual input stream from which the raw
> bytecode (or source code) can be read.
>
> This mechanism would need to be gone around for the proposed
> "classloader plugin". Instead one would need to pass a raw byte array
> to Soot, and Soot would then need to discover the class name from that
> bytecode. The actual conversion from bytecode to Jimple happens in
> soot.coffi.Util.resolveFromClassFile(SootClass, InputStream, List), if
> I am not mistaken. This method could be used to convert the incoming
> byte array (via a ByteArrayInputStream) to a SootClass. Also,
> Options.v().set_allow_phantom_refs(true) must be called to enable
> phantom refs.
>
> I would recommend to not tamper with Soot's existing main method, and
> leave the mechanism there intact. Instead I would recommend to
> actually define a new ClassFileTransformer that invokes the components
> mentioned above correctly.
>
> That's a rough outline of what would need to be done (I think). Let me
> know whether this is helpful to you.
>
> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20111230/3741d4f7/attachment.html