[Soot-list] Using soot within a javaagent

[Eric Bodden]

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