Modularize Soot and Deprecate Some Modules

[malaverdiere]

Soot currently is semi-modularized. Some mandatory dependencies (e.g. Jasmin) and optional ones (e.g. Probe, Paddle) are organized separately.

However, many modules within Soot are merged in the same code base. Some modules are unmaintained currently.

The core Soot project should contain the following modules:

• Jimple and Jimple processing packs that are enabled by default
• Bytecode front-end
• Up-to-date Java front-end
• Heros implementation supporting Jimple
• Spark
• Geometric-encoded context-senstitive variant of Spark
• Output to Jimple and Java bytecode

Optional modules should be:

• Paddle (already external)
• Dava (already external)
• Probe (already external)
• Heros (already external)
• Eclipse plug-in
• Java 1.4 Polyglot front-end
• Shimple and all Shimple processing packs
• Optional (not enabled by default) Jimple transformers
• Output to Shimple, jimp, shimp, baf, b, grimple, grimp, dava, templates
• Annotation-related transformers

[bergerbd]

I think one of the first steps would be to create some kind of plugin mechanism (and a new parameter/configuration framework) for the existing analysis. This enables us to add analysis without creating a new main method. Therefore, it will be easier to test/integrate analysis written by others (just add the jar to the classpath and an entry to the configuration file). Then we can split the existing Soot codebase into different projects (no idea about dependencies between those analysis).

[malaverdiere]

I am thinking of the JDBC drivers right how. They get registered on class creation and then they are available to the application.

So we could have some singleton for registering new options and new packs. The programmer just need to refer to the class, and it will get registered.

There could be a way to make it more automatic, maybe using Reflection and passing the names of the 'bootstrapping' classes as command-line parameters?

Marc-André Laverdière-Papineau Doctorant - PhD Candidate

On 04/25/2013 01:24 AM, Bernhard Berger wrote:

I think one of the first steps would be to create some kind of plugin mechanism (and a new parameter/configuration framework) for the existing analysis. This enables us to add analysis without creating a new main method. Therefore, it will be easier to test/integrate analysis written by others (just add the jar to the classpath and an entry to the configuration file). Then we can split the existing Soot codebase into different projects (no idea about dependencies between those analysis).

— Reply to this email directly or view it on GitHub https://github.com/Sable/soot/issues/43#issuecomment-16989272.