Re: Changes from 1.2.4

[Ondrej Lhotak <olhotak@sable.mcgill.ca>]

On Wed, Sep 10, 2003 at 08:46:59PM -0700, Stephen Andrew Neuendorffer wrote:
> I'm finally getting around to upgrading to 2.0.1, but I've run into some 
> difficulties...
> 
> It used to be that a transformer declared the valid options, which was 
> convenient for the rest of the world, if not for you guys, since it made a 
> transformer self contained...  Can this come back?

The reason for this is historical, namely that some Transformers are
repeated in different Transforms, and have different options in each
one. Under the old system, there were default defaults, which were
overridden by default options in the Transformer, which could be
overridden by default options in the Transform, which were then further
overridden by default options passed in from the pack, which were
finally overridden by the options finally specified on the command line.
We're trying to reduce the number of places where the set of options can
be specified, to reduce confusion.

It may be possible to somehow merge transform and transformer, and for
the relatively rare case when a transformer appears in more than one
transform, we could just have (possibly anonymous) subclasses of the
transformer. But I think some people trying to reuse existing
transformers might object to this strongly.

> Also useful would be a set of required options that would be checked.

You mean you want to add a phase that forces the user to specify
options, rather than just accept the default values? This goes against
the idea of being able to just run "java soot.Main Classname".

> This is a stupid warning message...  I put the phase in the right pack, and 
> the options match up and everything...  just let me do it.:
> Or, is there an option to turn this off?
> 	Warning: Phase wjtp.hack is not a standard Soot phase listed in XML files.

It's a warning, not an error. The reason it's there is that in the
standard Soot, we don't want to have any phases that are not specified
and documented in the XML files, to ensure that the documentation
remains consistent with the implementation, and that specified options
for the standard phases are checked against the list of available
options.

I suppose we could have some sort of global flag to turn this warning
off so that people writing extensions could turn it off, while the
standard Soot would still have it.

> Have you guys considered using a hierarchy pattern for Packs?  Namely the 
> code below is obnoxious because it means that new toplevel packs cannot be 
> added...  This used to not be a problem, because I could put everything 
> into wjtp, but now that is tied to spark...

How is wjtp tied to Spark? I don't understand.

We did consider a hierarchy of packs, but decided against it, again for
historical reasons. There are still things that Soot does in between
packs that are not standard packs and phases, and we were unable to
agree on ways that this could be changed. Unfortunately, Soot is not
just a list of passes that always get executed one after another; it
takes various inputs and produces various outputs, taking possibly
very different paths along the way. This means that it's not enough to
just tell some root pack to "execute yourself and recursively all your
subpacks".

> Since I'm nitpicking, the difference between scene transformers and body 
> transformers is really stupid...  I don't see any reason why 
> BodyTransformers are needed other than convenience

There is a very fundamental reason. Originally, Soot was only
intra-procedural, and contained only BodyTransformers. For each method,
all of the body transformers would be executed in sequence. Then
everything associated with the method would be freed, and we would go
onto the next method. With SceneTransformers, you cannot do that; you
need to execute the SceneTransformers one after another on the whole
Scene. Currently, we first execute all the SceneTransformers that are
to be executed (if any), and then, for each method, for each
BodyTransformer, we execute it. This means that if you are not doing a
whole-program analysis (which many people don't), you don't need to have
all of the intermediate representations of all the methods loaded at the
same time; you can do one method at a time.

> I also have some flow analyses over a call graph... this used to work fine 
> since InvokeGraph was a HashMutableDirectedGraph, but CallGraph is 
> not..  Any thoughts on providing an adapter?  I don't really feel like 
> rewriting it...

You mean like a subclass of ForwardFlowAnalysis? The CallGraph contains
more information than the InvokeGraph used to, such as the types of
special call edges (such as those due to static initializers, thread
invocation, finalizers, etc.) that you have to decide how you want to
handle in your specific analyses. I think your best bet would be to use
the CallGraph to build some subclass of DirectedGraph containing the
edges that you're interested in, and then plug that into your flow
analysis. Building such a thing shouldn't be hard.

Ondrej

> Steve