Soot, a Tool for Analyzing and Transforming

Java Bytecode
Laurie Hendren, Patrick Lam, Jennifer Lhoták, Ondřej Lhoták and Feng Qian
McGill University

Special thanks to John Jorgensen and Navindra Umanee for help in preparing
Soot 2.0 and this tutorial.

Soot development has been supported, in part, by research grants from NSERC,
FCAR and IBM

[Link]

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 1
 Program and Cast

ACT I (Warming Up):

Introduction and Soot Basics (Laurie)
Intraprocedural Analysis in Soot (Patrick)
ACT II (The Home Stretch):
Interprocedural Analyses and Call Graphs
(Ondřej)
Attributes in Soot and Eclipse
(Ondřej,Feng,Jennifer)
Conclusion, Further Reading & Homework
(Laurie)

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 2
 Introduction and Soot Basics

What is Soot?
Soot: Past and Present
Soot Overview
IRs: Baf, Jimple, Shimple, Grimp, Dava
Soot as an end-user tool and Soot as an
Eclipse plugin

... switching gears ....

Jimple and Soot Implementation Basics

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 3
 What is Soot?

a free compiler infrastructure, written in Java

(LGPL)
was originally designed to analyze and
transform Java bytecode
original motivation was to provide a common
infrastructure with which researchers could
compare analyses (points-to analyses)
has been extended to include decompilation
and visualization

[Link]/soot/
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 4
 What is Soot? (2)

Soot has many potential applications:

used as a stand-alone tool (command line
or Eclipse plugin)
extended to include new IRs, analyses,
transformations and visualizations
as the basis of building new
special-purpose tools

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 5
 Soot: Past and Present

Started in 1996-97 with the development of

coffi by Clark Verbrugge and some first
prototypes of Jimple IR by Clark and Raja
Vallée-Rai.
First publicly-available versions of Soot 1.x
were associated with Raja’s [Link]. thesis
New contributions and releases have been
added by many graduate students at McGill
and research results have been the topics of
papers and theses.

[Link]/publications/
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 6
 Soot: Past and Present (2)

Soot 1.x has been used by many research

groups for a wide variety of applications. Has
also been used in several compiler courses.
Last version was 1.2.5.
Soot 2.0 and the first version of the Eclipse
Plugin have just been released - June 2003 -
JIT for PLDI 2003.
This tutorial is based on Soot 2.0.

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 7
 Soot Overview
Java SML Scheme Eiffel
source source source source

javac MLJ KAWA SmallEiffel

Eclipse
class files
SOOT

Produce Jimple 3−address IR

Analyze, Optimize and Tag

Generate Bytecode
Java
source

Optimized class files + attributes

Interpreter JIT Adaptive Engine Ahead−of−Time

Compiler

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 8
 Soot IRs

Baf: is a compact rep. of Bytecode (stack-based)

Jimple:is Java’s simple, typed, 3-addr
(stackless) representation
Shimple: is a SSA-version of Jimple
Grimp:is like Jimple, but with expressions
agGRegated
Dava:structured representation used for
Decompiling Java

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 9
 Soot as an end-user tool: Command-line

1. Install Java.
2. Download two .jar files (one for soot and one
for jasmin) and put them on your
CLASSPATH.

java [Link] --help

List options.
java [Link] --version
Print version information.

[Link]/software/#soot
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 10
 Command-line: processing classes

java [Link] Foo

Process [Link] in the current directory
and produce a new class file in
sootOutput/[Link].
java [Link] -f jimple Foo
Same as above, but produce Jimple in
sootOutput/[Link].
java [Link] -f dava Foo
Decompile [Link] and produce
[Link] in
sootOutput/dava/src/[Link].

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 11
 Command-line: optimizing classes

java [Link] -O Foo

Run intraprocedural optimizations and
produce optimized [Link].
java [Link] -O --app Foo
Run intraprocedural optimizations on
[Link] and all application classes
reachable from [Link].
java [Link] -W --app Foo
Perform whole program analysis and produce
optimized classes for [Link] and all
application classes reachable from Foo.

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 12
 Command-line: a more complex example

java [Link] -W -app -f jimple

-p jb use-original-names:true
-p [Link] on
-p [Link] simplify-offline:true
-p [Link] on
-p [Link] on -p [Link] off
Foo

Starting at [Link], process all reachable

classes in an interprocedural fashion and
produce Jimple as output for all application
classes.
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 13
 Command-line: a more complex example

java [Link] -W -app -f jimple

-p jb use-original-names:true
-p [Link] on
-p [Link] simplify-offline:true
-p [Link] on
-p [Link] on -p [Link] off
Foo

When producing the original Jimple from the

class files, keep the original variable names, if
available in the attributes (i.e. class file produced
with javac -g).
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 14
 Command-line: a more complex example

java [Link] -W -app -f jimple

-p jb use-original-names:true
-p [Link] on
-p [Link] simplify-offline:true
-p [Link] on
-p [Link] on -p [Link] off
Foo

Use Spark for points-to analysis and call graph,

with Spark simplifying the points-to problem by
collapsing equivalent variables.
Note: on is a short form for enabled:true.
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 15
 Command-line: a more complex example

java [Link] -W -app -f jimple

-p jb use-original-names:true
-p [Link] on
-p [Link] simplify-offline:true
-p [Link] on
-p [Link] on -p [Link] off
Foo
Turn on the intra and interprocedural optimizations phases (-W).
Enable common sub-expression elimination (cse).
Enable static method binding (smb) and disable static inlining
(si).

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 16
 Soot as an end-user tool: Eclipse Plugin

1. Install Java
2. Install Eclipse [Link]
3. Download one .jar file and unjar it into your Eclipse
plugin directory
4. Start Eclipse

IDE-based optimization, decompilation and

visualization
GUI for setting and storing Soot option configurations
tooltips for documentation on options
Eclipse views for Soot IRs
[Link]/software/#soot
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 17
 Switching Gears ... Let’s get dirty

Now we want to understand:

details of Jimple
internal workings of Soot
To work with Soot in this way, you should
download the complete package
[Link] which contains the complete
Java source, class files, Javadoc documentation,
Soot tutorials, source and compiled forms of the
plugin,and our modified jasmin assembler.

[Link]/software/#soot
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 18
 Jimple

Jimple is:
principal Soot Intermediate Representation
3-address code in a control-flow graph
a typed intermediate representation
stackless

Raja’s Thesis, CASCON99, CC2000, SAS2000

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 19
 Kinds of Jimple Stmts I

Core statements:
NopStmt
DefinitionStmt: IdentityStmt,
AssignStmt
Intraprocedural control-flow:
IfStmt
GotoStmt
TableSwitchStmt,LookupSwitchStmt
Interprocedural control-flow:
InvokeStmt
ReturnStmt, ReturnVoidStmt

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 20
 Kinds of Jimple Stmts II

ThrowStmt
throws an exception
RetStmt
not used; returns from a JSR
MonitorStmt: EnterMonitorStmt,
ExitMonitorStmt
mutual exclusion

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 21
 IdentityStmt

this.m();
Where’s the definition of this?
IdentityStmt:
Used for assigning parameter values and
this ref to locals.
Gives each local at least one definition point.
Jimple rep of IdentityStmts:
r0 := @this;
i1 := @parameter0;

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 22
 Context: other Jimple Stmts
public int foo([Link]) { // locals
r0 := @this; // IdentityStmt
r1 := @parameter0;

if r1 != null goto label0; // IfStmt

$i0 = [Link](); // AssignStmt

[Link](); // InvokeStmt
return $i0; // ReturnStmt

label0: // created by Printer

return 2;
}
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 23
 Converting bytecode → Jimple → bytecode

These transformations are relatively hard to design so

that they produce correct, useful and efficient code.
Worth the price, we do want a 3-addr typed IR.
raw bytecode typed 3-address code (Jimple)
◦ each inst has implicit ◦ each stmt acts explicitly
effect on stack on named variables
◦ no types for local ◦ types for each local
variables variable
◦ > 200 kinds of insts ◦ only 15 kinds of stmts

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 24
 Bytecode → Jimple

Performed in the jb phase.

Makes a naive translation from bytecode to
untyped Jimple, using variables for stack
locations.
splits DU-UD webs (so many different uses of
the stack do not interfere)
types locals (SAS 2000)
cleans up Jimple and packs locals
provides a good starting point for analysis
and optimization
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 25
 Jimple → Bytecode
Performed in the bb or gb phase.
A naive translation introduces many spurious
stores and loads.
Two approaches (CC 2000),
aggregate expressions and then generate
stack code; or
perform store-load and store-load-load
elimination on the naive stack code.
Second approach works better and produces
very good bytecode.
Produces bytecode that is different than what
javac produces, breaks immature JITs.
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 26
 Soot Data Structure Basics

Soot builds data structures to represent:

a complete environment (Scene)
classes (SootClass)
Fields and Methods (SootMethod,
SootField)
bodies of Methods (come in different
flavours, corresponding to different IR
levels, ie. JimpleBody)
These data structures are implemented using
OO techniques, and designed to be easy to
use and generic where possible.
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 27
 Soot Classes

Scene.v()

Scene (singleton)

getSootClass()
getField()
SootClass SootField getSignature()

getMethod()

SootMethod getSignature()

getActiveBody()

JimpleBody

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 28
 Body-centric View

SootMethod

getActiveBody()
getLocals()
JimpleBody Chain

getTraps()
getUnits()

Chain Chain

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 29
 Getting a UnitGraph

SootMethod

getActiveBody()
UnitGraph getBody()
getLocals()
JimpleBody Chain
new BriefUnitGraph()
getTraps()
getUnits()

Chain Chain
getUnits()

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 30
 What to do with a UnitGraph

getBody()
getHeads(), getTails()
getPredsOf(u), getSuccsOf(u)
getExtendedBasicBlockPathBetween
(from, to)

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 31
 Control-flow units

We create an OO hierarchy of units, allowing

generic programming using Units.

Unit: abstract interface

Inst: Baf’s bytecode-level unit
(load x)
Stmt: Jimple’s three-address code units
(z = x + y)
Stmt: also used in Grimp
(z = x + y * 2 % n;)

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 32
 Soot Philosophy on Units

Accesses should be abstract whenever

possible!
Accessing data:
getUseBoxes(), getDefBoxes(),
getUseAndDefBoxes()
(also control-flow information:)
fallsThrough(), branches(),
getBoxesPointingToThis(),
addBoxesPointingToThis(),
removeBoxesPointingToThis(),
redirectJumpsToThisTo()

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 33
 What is a Box?
s: x = y op z

AssignStmt AssignStmt

x OpExpr
VB VB
y z
x OpExpr

VB VB

y z
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 34
 What is a DefBox?

List defBoxes = [Link]();

method [Link]() returns a list of
ValueBoxes, corresponding to all Values
which get defined in ut, a Unit.
non-empty for IdentityStmt and
AssignStmt.
ut: x = y op z ;
getDefBoxes(ut) = { x }
(List containing a ValueBox
containing a Local)
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 35
 On Values and Boxes

Value value = [Link]();

getValue(): Dereferencing a pointer.

x →x
setValue(): mutates the value in the Box.

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 36
 On UseBoxes

Opposite of defBoxes.
List useBoxes = [Link]();
method [Link]() returns a list of
ValueBoxes, corresponding to all Values
which get used in ut, a Unit.
non-empty for most Soot Units.
ut: x = y op z ;

getUseBoxes(ut) = { y , z , y op z }
(List containing 3 ValueBoxes, 2
containing Locals & 1 Expr)
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 37
 Why Boxes?
Change all instances of y to 1:

AssignStmt AssignStmt

x OpExpr
VB VB
y z
x OpExpr

VB VB

y z
setValue() ??
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 38
 Search & Replace

/* Replace all uses of v1 in body with v2 */

void replace(Body body, Value v1, Value v2)
{ for (Unit ut : [Link]())
{ for (ValueBox vb : [Link]())
if( [Link]().equals(v1) )
[Link](v2);
}
}

replace(b, y, IntConstant.v(1));

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 39
 More Abstract Accessors: Stmt

Jimple provides the following additional

accessors for special kinds of Values:

containsArrayRef(),
getArrayRef(), getArrayRefBox()
containsInvokeExpr(),
getInvokeExpr(), getInvokeExprBox()
containsFieldRef(),
getFieldRef(), getFieldRefBox()

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 40
 Program and Cast

ACT I (Warming Up):

Introduction and Soot Basics (Laurie)
Intraprocedural Analysis in Soot (Patrick)
ACT II (The Home Stretch):
Interprocedural Analyses and Call Graphs
(Ondřej)
Attributes in Soot and Eclipse
(Ondřej,Feng,Jennifer)
Conclusion, Further Reading & Homework
(Laurie)

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 41
 Intraprocedural Outline

About Soot’s Flow Analysis Framework

Flow Analysis Examples
Live Variables
Branched Nullness
Adding Analyses to Soot

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 42
 Flow Analysis in Soot

Flow analysis is key part of compiler

framework
Soot has easy-to-use framework for
intraprocedural flow analysis
Soot itself, and its flow analysis framework,
are object-oriented.

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 43
 Four Steps to Flow Analysis

1. Forward or backward? Branched or not?

2. Decide what you are approximating.
What is the domain’s confluence operator?
3. Write equation for each kind of IR statement.
4. State the starting approximation.

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 44
 HOWTO: Soot Flow Analysis

A checklist of your obligations:

1. Subclass *FlowAnalysis
2. Implement abstraction: merge(), copy()
3. Implement flow function flowThrough()
4. Implement initial values:
newInitialFlow() and
entryInitialFlow()
5. Implement constructor
(it must call doAnalysis())

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 45
 HOWTO: Soot Flow Analysis II

Soot provides you with:

impls of abstraction domains (flow sets)
standard abstractions trivial to implement;
an implemented flow analysis namely,
doAnalysis() method: executes
intraprocedural analyses on a CFG using a
worklist algorithm.

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 46
 Flow Analysis Hierarchy

AbstractFlowAnalysis

FlowAnalysis BranchedFlowAnalysis

Forward- Backward- Forward-

[Link]
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 47
 Soot Flow Analyses

AbstractFlowAnalysis

FlowAnalysis BranchedFlowAnalysis

Forward-
Forward- Backward-

Casts Nullness
PRE analy’s PRE analy’s
Avail. Expr. Liveness
Array Bds
[Link]
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 48
 Backward vs. Forward Analyses
A forward analysis computes OUT from IN:
i
s
flow dir
fs (i)
fs (i)
t

ft (fs (i))
A backward analysis computes IN from OUT:
fs (ft (i))
s
flow dir
ft (i)
ft (i)
t
i
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 49
 Outline: Soot Flow Analysis Examples

Will describe how to implement a flow analysis in

Soot and present examples:
live locals
branched nullness testing

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 50
 Running Example 1: Live Variables
A local variable v is live at s if there exists some
statement s′ using v and a control-flow path from
s to s′ free of definitions of v.

{z, x}
y=x
{z, y}

{z, y} {y}
{z, y}
x=y z=2
{z, y}
{z, y}
b=y
{z}

{z}
a=z
{}

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 51
 Steps to a Flow Analysis

As we’ve seen before:

1. Subclass *FlowAnalysis
2. Implement abstraction: merge(), copy()
3. Implement flow function flowThrough()
4. Implement initial values:
newInitialFlow() and
entryInitialFlow()
5. Implement constructor
(it must call doAnalysis())

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 52
 Step 1: Forward or Backward?

Live variables is a backward flow analysis, since

flow fn computes IN sets from OUT sets.

In Soot, we subclass BackwardFlowAnalysis.

class LiveVariablesAnalysis
extends BackwardFlowAnalysis

[Link]
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 53
 Step 2: Abstraction domain
Domain for Live Variables: sets of Locals
e.g. {x, y, z}

Partial order is subset inclusion

Merge operator is union

In Soot, we use the provided ArraySparseSet

implementation of FlowSet.

[Link]
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 54
 Implementing an Abstraction
Need to implement copy(), merge() methods:

dest
copy dir CFG
src

copy() brings IN set to predecessor’s OUT set.

merge dir
dest = src1 ⊲⊳ src2

src1 src2

merge() joins two IN sets to make an OUT set.

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 55
 More on Implementing an Abstraction

Signatures:

void merge(Object src1, Object src2,

Object dest);
void copy(Object src, Object dest);

We delegate implementation to FlowSet.

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 56
 Flow Sets and Soot

Using a FlowSet is not mandatory, but helpful.

Impls: ToppedSet, ArraySparseSet,

ArrayPackedSet
// c = a ∩ b // c = a ∪ b
[Link](b, c); [Link](b,c);

// d = c // d = d ∪ {v}
[Link](d); [Link](v);

[Link]
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 57
 Digression: types of FlowSets

Which FlowSet do you want?

ArraySparseSet: simple list
foo bar z
(simplest possible)
ArrayPackedSet: bitvector w/ map
00100101 10101111 10000000
(can complement, need universe)
ToppedSet:
FlowSet & isTop()
(adjoins a ⊤ to another FlowSet)

[Link].*Set
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 58
 Step 2: copy() for live variables

protected void copy(Object src,

Object dest) {
FlowSet sourceSet = (FlowSet)src,
destSet = (FlowSet) dest;

[Link](destSet);
}

Use copy() method from FlowSet.

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 59
 Step 2: merge() for live variables

In live variables, a variable v is live if there exists

any path from d to p, so we use union.

Like copy(), use FlowSet’s union:

void merge(...) {
// [cast Objects to FlowSets]
[Link](src2Set, destSet);
}
One might also use intersection(), or
implement a more exotic merge.

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 60
 Step 3: Flow equations

Goal: At a unit like x = y * z:

kill def x;
gen uses y, z.
How? Implement this method:
protected void flowThrough
(Object srcValue,
Object u,
Object destValue)

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 61
 Step 3: Casting

Soot’s flow analysis framework is polymorphic.

Need to cast to do useful work.

Start by:
casting srcValue, destValue to FlowSet.
casting u to Unit ut.
In code:
FlowSet src = (FlowSet)srcValue,
dest = (FlowSet)destValue;
Unit ut = (Unit)u;

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 62
 Step 3: Copying

Need to copy src to dest to allow manipulation.

dest
copy dir CFG
src

[Link] (dest);

Use FlowSet methods.

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 63
 Step 3: Implementing flowThrough

Must decide what happens at each statement (in

general, need to switch on unit type):

IN[ut]

ut flowThrough

OUT[ut]

IN[ut] = flowThrough(OUT[ut])
= OUT[ut] \ kills[ut] ∪ gens[ut]
flowThrough is the brains of a flow analysis.
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 64
 Step 3: flowThrough for live locals

A local variable v is live at s if there exists some

statement s′ containing a use of v, and a
control-flow path from s to s′ free of def’ns of v.

Don’t care about the type of unit we’re analyzing:

Soot provides abstract accessors to values used
and defined in a unit.

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 65
Step 3: Implementing flowThrough: removing kills

// Take out kill set:

// for each local v def’d in
// this unit, remove v from dest
for (ValueBox box : [Link]())
{
Value value = [Link]();
if( value instanceof Local )
[Link]( value );
}

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 66
 Step 3: Implementing flowThrough: adding gens
// Add gen set
// for each local v used in
// this unit, add v to dest
for (ValueBox box : [Link]())
{
Value value = [Link]();
if (value instanceof Local)
[Link](value);
}
N.B. our analysis is generic, not restricted to
Jimple.

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 67
 Step 4: Initial values

• Soundly initialize IN, OUT sets prior to

analysis.
Create initial sets
Object newInitialFlow()
{return new ArraySparseSet();}

Create initial sets for exit nodes

Object entryInitialFlow()
{return new ArraySparseSet();}

Want conservative initial value at exit nodes,

optimistic value at all other nodes.
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 68
 Step 5: Implement constructor

LiveVariablesAnalysis(UnitGraph g)
{
super(g);

doAnalysis();
}
Causes the flow sets to be computed, using
Soot’s flow analysis engine.

In other analyses, we precompute values.

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 69
 Enjoy: Flow Analysis Results

You can instantiate an analysis and collect

results:
LiveVariablesAnalysis lv =
new LiveVariablesAnalysis(g);

// return SparseArraySets
// of live variables:
[Link](s);
[Link](s);

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 70
 Running Example 2: Branched Nullness
A local variable v is non-null at s if all
control-flow paths reaching s result in v being
assigned a value different from null.
{}
{}
if (y==null) {y}
T F
{} {y}
{x}
x=new foo() [Link]()
{x, y}

y=null
{x}

{x}
y=b.f {x, b}

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 71
 HOWTO: Soot Flow Analysis

Again, here’s what to do:

1. Subclass *FlowAnalysis
2. Implement abstraction: merge(), copy()
3. Implement flow function flowThrough()
4. Implement initial values:
newInitialFlow() and
entryInitialFlow()
5. Implement constructor
(it must call doAnalysis())

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 72
 Step 1: Forward or Backward?

Nullness is a branched forward flow analysis,

since flow fn computes OUT sets from IN sets,
sensitive to branches

Now subclass ForwardBranchedFlowAnalysis.

class NullnessAnalysis
extends ForwardBranchedFlowAnalysis {

[Link]
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 73
 Step 2: Abstraction domain
Domain: sets of Locals known to be non-null
Partial order is subset inclusion.

(More complicated abstractions possible∗ for this

problem; e.g. ⊥, ⊤, null, non-null per-local.)

Again use ArraySparseSet to implement:

void merge(Object in1, Object in2,

Object out);
void copy(Object src, Object dest);

∗
see [Link]
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 74
 Implementing an Abstraction
For a forward analysis, copy and merge mean:

src
copy dir CFG
dest

copy() brings OUT set to predecessor’s IN set.

src1 src2

merge dir
dest = src1 ⊲⊳ src2

merge() joins two OUT sets to make an IN set.

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 75
 Step 2: copy() for nullness

Same as for live locals.

protected void copy(Object src,
Object dest) {
FlowSet sourceSet = (FlowSet)src,
destSet = (FlowSet) dest;

[Link](destSet);
}

Use copy() method from FlowSet.

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 76
 Step 2: merge() for nullness

In branched nullness, a variable v is non-null if it

is non-null on all paths from start to s, so we
use intersection.

Like copy(), use FlowSet method – here,

intersection():
void merge(...) {
// [cast Objects to FlowSets]
[Link](srcSet2,
destSet);
}

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 77
 Step 3: Branched Flow Function

Need to differentiate between branch and

fall-through OUT sets.
protected void
flowThrough(Object srcValue,
Unit unit,
List fallOut,
List branchOuts)
fallOut is a one-element list.
branchOuts contains a FlowSet for each
non-fallthrough successor.

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 78
 Step 3: Flow equations

We do the following things in our flow function:

Create copy of src set.

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 79
 Step 3: Flow equations

We do the following things in our flow function:

Create copy of src set.

Remove kill set (defined Locals).
y in y = [Link];

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 79
 Step 3: Flow equations

We do the following things in our flow function:

Create copy of src set.

Remove kill set (defined Locals).
y in y = [Link];
Add gen set.
x in [Link]();

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 79
 Step 3: Flow equations

We do the following things in our flow function:

Create copy of src set.

Remove kill set (defined Locals).
y in y = [Link];
Add gen set.
x in [Link]();
Handle copy statements.

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 79
 Step 3: Flow equations

We do the following things in our flow function:

Create copy of src set.

Remove kill set (defined Locals).
y in y = [Link];
Add gen set.
x in [Link]();
Handle copy statements.
Copy to branch and fallthrough lists.

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 79
 Step 3: Flow equations

We do the following things in our flow function:

Create copy of src set.

Remove kill set (defined Locals).
y in y = [Link];
Add gen set.
x in [Link]();
Handle copy statements.
Copy to branch and fallthrough lists.
Patch sets for if statements.

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 79
 Step 4: Initial values

Initialize IN, OUT sets.

Create initial sets (⊤ from constr.)
Object newInitialFlow() {
{ return [Link](); }

Create entry sets (emptySet from constr.)

Object entryInitialFlow()
{ return [Link](); }
(To be created in constructor!)

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 80
 Step 5: Constructor: Prologue

Create auxiliary objects.

public NullnessAnalysis(UnitGraph g)
{
super(g);

unitToGenerateSet = new HashMap();

Body b = [Link]();

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 81
 Step 5: Constructor: Finding All Locals

Create flowsets, finding all locals in body:

emptySet = new ArraySparseSet();
fullSet = new ArraySparseSet();

for (Local l : [Link]()) {

if ([Link]()
instanceof RefLikeType)
[Link](l);
}

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 82
 Step 5: Creating gen sets

Precompute, for each statement, which locals

become non-null after execution of that stmt.

x gets non-null value:

x = *, where * is NewExpr, ThisRef, etc.
successful use of x:
x.f, x.m(), entermonitor x, etc.

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 83
 Step 5: Constructor: Doing work

Don’t forget to call doAnalysis()!

...

doAnalysis();
}
}

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 84
 Enjoy: Branched Flow Analysis Results
To instantiate a branched analysis & collect
results:
NullnessAnalysis na=new NullnessAnalysis(b);

// a SparseArraySet of non-null variables.

[Link](s);

// another SparseArraySet
if ([Link]()) [Link](s);

// a List of SparseArraySets
if ([Link]()) [Link](s);

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 85
 Adding transformations to Soot (easy way)

1. Implement a BodyTransformer or
a SceneTransformer
internalTransform method
does the transformation
2. Choose a pack for your transformation
(usually jtp)
3. Write a main method that adds the transform
to the pack, then runs Soot’s main
4. (Optional) If your transformation needs
command-line options, call
setDeclaredOptions()
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 86
 On Packs
Want to run a set of Transformer objects with
one method call.
⇒ Group them in a Pack.
Soot defines default Packs which are run
automatically. To add a Transformer to the
jtp Pack:
Pack jtp = G.v().PackManager().
getPack("jtp");
[Link](new Transform("[Link]",
new NullTransformer()));
[Link](new Transform("[Link]",
new NullnessAnalysisColorer()));
[Link]
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 87
 Extending Soot (hard way)

Some don’t like calling [Link]().

What does main() do?
1. processCmdLine()
2. Scene.v().loadNecessaryClasses()
3. PackManager.v().runPacks()
4. PackManager.v().writeOutput()
You can do any or all of these yourself:
Options.v() contains setter methods for all
options

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 88
 Running Soot more than once

All Soot global variables are stored in G.v()

[Link]() re-initializes all of Soot

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 89
 Generating Jimple

.class coffi

jb Jimple

Jimple
.jimple
parser

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 90
 Intra-procedural packs

stp sop sap Shimple

Jimple jtp jop jap Jimple

bb bop tag Baf

gb gop Grimp

Dava Jasmin Output

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 91
 Soot Pack Naming Scheme

w? (j|s|b|g)(b|t|o|a)p

w ⇒ Whole-program phase
j, s, b, g ⇒ Jimple, Shimple, Baf, Grimp
b, t, o, a ⇒
(b) Body creation
(t) User-defined transformations
(o) Optimizations with -O option
(a) Attribute generation
The p is sometimes silent.
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 92
 Soot Packs (Jimple Body)

jb converts naive Jimple generated from

bytecode into typed Jimple with split variables

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 93
 Soot Packs (Jimple)

jtp performs user-defined intra-procedural

transformations
jop performs intra-procedural optimizations
CSE, PRE, constant propagation, . . .
jap generates annotations using whole-program
analyses
null-pointer check
array bounds check
side-effect analysis

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 94
 Soot Packs (Back-end)

bb performs transformations to create Baf

bop performs user-defined Baf optimizations

gb performs transformations to create Grimp

gop performs user-defined Grimp optimizations

tag aggregates annotations into

bytecode attributes

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 95
 Program and Cast

ACT I (Warming Up):

Introduction and Soot Basics (Laurie)
Intraprocedural Analysis in Soot (Patrick)
ACT II (The Home Stretch):
Interprocedural Analyses and Call Graphs
(Ondřej)
Attributes in Soot and Eclipse
(Ondřej,Feng,Jennifer)
Conclusion, Further Reading & Homework
(Laurie)

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 96
 Interprocedural Outline

Soot’s whole-program mode

Call graph
Points-to information (Spark)
(Spark was my [Link]. thesis)

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 97
 Soot’s whole-program mode

Use -w switch for whole-program mode

Enables cg, wjtp, wjap packs
Whole-program information from these packs
available to rest of Soot through Scene
Call graph
Points-to information
Whole program analyzed; only application
classes written out, not library classes
To also enable wjop, use -W
Method inlining, static binding
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 98
 Soot Packs (Whole Program)

cg generates a call graph using CHA or more

precise methods
wjtp performs user-defined whole-program
transformations
wjop performs whole-program optimizations
static inlining
static method binding
wjap generates annotations using
whole-program analyses
rectangular array analysis

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 99
 Soot phases

jb jtp jop jap bb tag

jb jtp jop jap bb tag

wjop

wjap
wjtp
cg

jb jtp jop jap bb tag

jb jtp jop jap bb tag

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 100
 Call Graph

Collection of edges representing all method

invocations known to Soot
explicit method invocations
implicit invocations of static initializers
implicit calls of [Link]()
implicit calls of finalizers
implicit calls by AccessController
...
Filter can be used to select specific kinds
of edges

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 101
 Call Graph Edge
Each Edge contains
Source method
Source statement (if applicable)
Target method
Kind of edge

source m. source stmt. target m. kind

• • • VIRTUAL

foo() { bar() {
[Link](); /* */
} }
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 102
 Edge Kinds
/** Due to explicit invokestatic instruction. */
public static final int STATIC = 1;
/** Due to explicit invokevirtual instruction. */
public static final int VIRTUAL = 2;
/** Due to explicit invokeinterface instruction. */
public static final int INTERFACE = 3;
/** Due to explicit invokespecial instruction. */
public static final int SPECIAL = 4;
/** Implicit call to static initializer. */
public static final int CLINIT = 5;
/** Implicit call to [Link]() due to [Link]() call. */
public static final int THREAD = 6;
/** Implicit call to [Link](). */
public static final int EXIT = 7;
/** Implicit call to non-trivial finalizer from constructor. */
public static final int FINALIZE = 8;
/** Implicit call to run() through [Link](). */
public static final int PRIVILEGED = 9;
/** Implicit call to constructor from [Link](). */
public static final int NEWINSTANCE = 10;
[Link]
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 103
 Querying Call Graph

edgesOutOf(SootMethod) iterator over

edges with given source method
edgesOutOf(Unit) iterator over edges with
given source statement
edgesInto(SootMethod) iterator over edges
with given target method
main() [Link](); [Link]() VIRTUAL
main() [Link](); [Link]() VIRTUAL
main() [Link](); [Link]() VIRTUAL
bar() [Link](); [Link]() VIRTUAL
[Link]
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 104
 Querying Call Graph

edgesOutOf(SootMethod) iterator over

edges with given source method
edgesOutOf(Unit) iterator over edges with
given source statement
edgesInto(SootMethod) iterator over edges
with given target method
main() [Link](); [Link]() VIRTUAL
main() [Link](); [Link]() VIRTUAL
main() [Link](); [Link]() VIRTUAL
bar() [Link](); [Link]() VIRTUAL
[Link]
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 105
 Adapters

Adapters make an iterator over edges into an

iterator over
Sources source methods
Units source statements
Targets target methods

src1 stmt1 tgt1 kind1 src1

src2 stmt2 tgt2 kind2 src2
src3 stmt3 tgt3 kind3 src3

< [Link].{Sources,Units,Targets}
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 106
 Code Example
void mayCall( SootMethod src ) {
CallGraph cg =
Scene.v().getCallGraph();
Iterator targets =
new Targets([Link](src));

while( [Link]() ) {
SootMethod tgt =
(SootMethod) [Link]();
[Link]( ""+
src+" may call "+tgt );
}
}
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 107
 Reachable Methods

ReachableMethods object keeps track of

which methods are reachable from entry
points

contains(SootMethod) tests whether

method is reachable
listener() returns an iterator over reachable
methods

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 108
 Code Example

ReachableMethods rm =
Scene.v().getReachableMethods();

if( [Link]( myMethod ) )

// myMethod is reachable

Iterator it = [Link]();
while( [Link]() ) {
SootMethod method =
(SootMethod) [Link]();
// method is reachable
}
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 109
 Transitive Targets

TransitiveTargets class takes a

CallGraph and optional Filter to select
edges

iterator(SootMethod) iterator over methods

transitively called from given method
iterator(Unit) iterator over methods
transitively called from targets of given
statement

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 110
 Implementation Big Picture

Entry Points

methods
Scene Call Graph
methods
edges edges
edges

Reachable Call Graph

Points-to
Methods Builder
receiver types
methods

Naive Spark

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 111
 Points-to analysis

Default points-to analysis assumes that any

pointer can point to any object
Spark provides variations of
context-insensitive subset-based points-to
analysis
Work in progress on context-sensitive
analyses

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 112
 Spark settings

-p [Link] on turns on Spark

Spark used for both call graph, and
points-to information
Default setting is on-the-fly call graph,
field-sensitive, most efficient algorithm and
data structures
-p [Link] vta Spark as VTA
-p [Link] rta Spark as RTA

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 113
 PointsToAnalysis interface

reachingObjects(Local) returns PointsToSet

of objects pointed to by a local variable
x = y
reachingObjects(SootField) returns
PointsToSet of objects pointed to by a
static field
x = C.f
reachingObjects(Local,SootField) returns
PointsToSet of objects pointed to by given
instance field of the objects pointed to by
local variable
x = y.f
[Link]
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 114
 PointsToSet interface

possibleTypes() returns a set of the possible

types of the objects in the points-to set
hasNonEmptyIntersection(PointsToSet) tells us
whether two points-to sets may overlap
(whether the pointers may be aliased)

[Link]
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 115
 If I want to know...

... the types of the receiver o in the call:

o.m(...)

Local o;
PointsToAnalysis pa =
Scene.v().getPointsToAnalysis();
PointsToSet ptset =
[Link]( o );
[Link] types =
[Link]()

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 116
 If I want to know...

... whether x and y may be aliases in

x.f = 5;
y.f = 6;
z = x.f;

Local x, y;
PointsToSet xset =
[Link]( x );
PointsToSet yset =
[Link]( y );
if([Link](yset))
// they’re possibly aliased
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 117
 SideEffectTester interface

Reports side-effects of any statement, including

calls
newMethod(SootMethod) tells the side-effect
tester that we are starting a new method
unitCanReadFrom(Unit,Value) returns true
if the Unit (statement) might read the Value
unitCanWriteTo(Unit,Value) returns true
if the Unit (statement) might write the Value

[Link]
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 118
 Implementations of SideEffectTester

NaiveSideEffectTester
is conservative
does not use call graph or points-to
information
does not require whole-program mode
PASideEffectTester
uses current call graph
uses current points-to information
this may be naive points-to information

[Link]
<
[Link] Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 119
 Program and Cast

ACT I (Warming Up):

Introduction and Soot Basics (Laurie)
Intraprocedural Analysis in Soot (Patrick)
ACT II (The Home Stretch):
Interprocedural Analyses and Call Graphs
(Ondřej)
Attributes in Soot and Eclipse
(Ondřej,Feng,Jennifer)
Conclusion, Further Reading & Homework
(Laurie)

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 120
 Motivation of Soot Attributes

We often want to attach annotations to code

to convey low-level analysis results, such
as register allocation or array bounds
check elimination to a VM
to convey analysis results to humans
to record profiling information
Soot provides a framework to support the
embedding of custom, user-defined attributes
in class files

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 121
 Java class file attributes

Attributes of class_info, method_info,

field_info, and Code_attribute structures
In fact: Code is an attribute of a method
Standard attributes: SourceFile,
ConstantValue, Exceptions,
LineNumberTable, LocalVariableTable
VM is required to ignore attributes it does not
recognize

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 122
 Attribute format

The VM spec defines the format of attributes:

attribute_info {
u2 attribute_name_index;
u4 attribute_length;
u1 info[attribute_length];
}

attribute name index, the index of the attribute’s

name in the class files’ Constant Pool
attribute length, the length of the attribute’s data
info, an array of raw attribute data

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 123
 Attributes and Soot (overview)
Eclipse

Class File Jimple IR Jasmin IR Class File

LineNumber Hosts Attributes old & new
LocalVariable Tags (text−based) attributes
...... (Attributes)

Parsing existing Adding new attributes Aggregating and

attributes from analysis results encoding
or other sources

Soot parses several standard attributes

New attributes can be created and attached
Users can design their own attribute format
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 124
 Tags in Soot Internals

Soot Java class file

SootClass class_info
SootField field_info
SootMethod method_info
Body Code_attribute
Unit

ValueBox
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 125
 Hosts

Hosts are objects that can hold Tags:

package [Link];
public interface Host {
public void addTag (Tag t);
public Tag getTag (String aName);
public List getTags ();
public void removeTag (String name);
public boolean hasTag (String aName);
}
Implementations:
SootClass, SootField, SootMethod, Body, Unit, ValueBox

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 126
 Tags

Tags are objects that can be attached to Hosts:

package [Link];
public interface Tag {
public String getName ();
public byte[] getValue ()
throws AttributeValueException;
public String toString();
}

Attribute attached to class file structures (class, field,

method)
Generic tags attached to Units or ValueBoxes
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 127
 Tag Hierarchy

interface Tag
byte[] getValue()

interface Attribute
void setValue(byte[])

class LineNumberTag
class GenericAttribute abstract class JasminAttribute class BytecodeOffsetTag
class ArrayNullCheckTag
byte[] decode( ...... )
class FieldRWTag
String getJasminValue(......) etc ......

class CodeAttribute

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 128
 Special case: attributes of Code_attribute

Jimple Baf code_attribute Jasmin

...... ...... tag label1:
a=b[i]; a=b[i]; tag iaload
...... tag ...... label2:
tag
getfield tag getfield getfield
.code_attribute
NullCheckAttribute
TagAggregator %label1%BA==

[Link]()

TagAggregator aggregates tags of

Units/ValueBoxes to CodeAttribute
CodeAttribute is a table of (pc, value) pairs in
class file
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 129
 Choosing an Aggregator

One Jimple statement may translate to

multiple bytecode instructions

Jimple Bytecode
x = y.f load y
getfield f
store x
Which instruction(s) should get the tags?

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 130
 Choosing an Aggregator

ImportantTagAggregator
attaches tag to the “most important” instruction
(field reference, array reference, method
invocation)
Used for array bounds check, null pointer
check, side-effect attributes
FirstTagAggregator
attaches tag to the first instruction
Used for line number table attribute
Easy to make your own . . .

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 131
 TagAggregator

public abstract class TagAggregator

extends BodyTransformer {
......
abstract boolean wantTag(Tag t);
abstract void considerTag(Tag t, Unit u);
abstract String aggregatedName();
void internalTransform(Body b, ... ) {
......
}
}

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 132
 ImportantTagAggregator
abstract class ImportantTagAggregator
extends TagAggregator {
/** Decide whether this tag
* should be aggregated by
* this aggregator. */
public abstract boolean
wantTag( Tag t );

/** Return name of the resulting

* aggregated tag. */
public abstract String
aggregatedName();
}
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 133
 Howto for creating new attributes

Create a new Tag class, decide which

structure is the host
If the tag is for Units, write a tag aggregator
by extending TagAggregator or one of its
subclasses
Parse attributes in bytecode consumer

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 134
 Example: nullness attribute

Step 1: create NullCheckTag

class NullCheckTag {
public String getName() { return "NullCheckTag"; }
private byte value = 0;
public byte[] getValue() {
byte[] bv = new byte[1];
bv[0] = value;
return bv;
}
public void toString() {
return ((value==0)?"[not null]":"[unknown]");
}
}

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 135
 Example: nullness attribute

Step 2: attach tags to units after analysis

boolean needCheck;
[Link](new NullCheckTag(needCheck));

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 136
 Example: nullness attribute

Step 3: create a NullTagAggregator

[Link](new Transform("[Link]",
NullTagAggregator.v()));

class NullTagAggregator
extends ImportantTagAggregator {

public boolean wantTag(Tag t) {

return (t instanceof NullCheckTag);
}
public String aggregatedName() {
return "NullCheckAttribute";
}
}
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 137
 Code attribute format

Attributes of Code_attribute extends

JasminAttribute which generates textual
representation of (label, value) pairs:
String getJasminValue(Map instToLabel);
e.g. "NullCheckAttribute":
null_check_attribute {
u2 attribute_name_index;
u4 attribute_length;
{ u2 pc;
u1 data;
} [attribute_length/3];
}

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 138
 Motivation of Soot Attributes in Eclipse

The Soot - Eclipse plug-in provides a

mechanism for viewing attribute information
in visual ways within Eclipse.
This can aid:
software visualization
program understanding
analysis debugging

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 139
 Visual Representations

Three visual representations of attribute

information:
Text displayed in tooltips
Color highlighting of chunks of code
Pop-up links

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 140
 String Tags

StringTags attach a string of information to a

Host.
[Link](new StringTag(val+": NonNull"));

The Soot - Eclipse plug-in displays the string

as a tooltip when the mouse hovers over a
line of text in the Java editor and Jimple
editor.

[Link]
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 141
 Color Tags

ColorTags attach a color to a Host.

[Link](new ColorTag([Link]));
[Link](new ColorTag(255, 0, 0));

The Soot - Eclipse plug-in highlights the

background color of the text in the editor at
the appropriate positions with the given color
in the Jimple editor.

[Link]
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 142
 Link Tags

LinkTags attach a string of information, and a

link to another part of code to a Host.
String text = "Target:"+[Link]();
Host h = m;
String cName = [Link]().getName();
[Link](new LinkTag(text, h, cName));

The Soot - Eclipse plug-in displays link which

jumps to a another part of the code when
clicked in the Jimple Editor.

[Link]
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 143
 Program and Cast

ACT I (Warming Up):

Introduction and Soot Basics (Laurie)
Intraprocedural Analysis in Soot (Patrick)
ACT II (The Home Stretch):
Interprocedural Analyses and Call Graphs
(Ondřej)
Attributes in Soot and Eclipse
(Ondřej,Feng,Jennifer)
Conclusion, Further Reading & Homework
(Laurie)

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 144
 Conclusion

Have introduced Soot, a framework for

analyzing, optimizing, tagging and visualizing
Java bytecode.
Have shown the basics of using Soot as a
stand-alone tool and also how to add new
functionality to Soot.
Now for some homework and reading.

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 145
 Homework

Try out Soot

Super easy: Soot as a stand-alone tool,
Eclipse plugin
Easy: implement a new intraprocedural
analysis and generate tags for it.
More challenging: implement whole program
analysis, toolkit or a new IR.
Please stay in touch, tell us how you are
using Soot and contribute back any new
additions you make.

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 146
 Resources

Main Soot page: [Link]/soot/

Theses and papers:
[Link]/publications/
Tutorials: [Link]/soot/tutorial/
Javadoc: in main Soot distribution,
[Link]/software/#soot and also
online at [Link]/soot/doc/.
Mailing lists:
[Link]/soot/#mailingLists
Soot in a Course:
[Link]/˜hendren/621/
<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 147
 Further reading

Raja’s thesis, CASCON

Introduction to Soot (1.x):
99, CC 2000, SAS 2000
Initial design of attributes: CC 2001
Array bounds checking elimination: Feng’s thesis,
CC 2002
Decompiling: Jerome’s thesis, WCRE 2001, CC
2002
Ondřej’s thesis, CC 2003, PLDI
Points-to analysis:
2003 (BDD-based)

<
Soot, a Tool for Analyzing and Transforming Java Bytecode – p. 148