Translating Jimple code into intermediate representation.
Intermediate representation (IR) is simplified compared to the Jimple code in the following ways:
- Only variables of type
String
, StringBuffer
,
StringBuilder
or array (of any dimension) of
String
are retained. Only operations on these types occur in the IR.
Variables declared as a supertype of one of those, such as Object
or Serializable
,
are also retained.
- All control constructs are abstracted away. Remaining is a conservative control flow graph of IR statements.
The graph includes edges corresponding to exception control flow.
- Each method invocation has exactly one possible target. For virtual invocations, the control-flow is split
and a separate invocation is created for each possible target, defined by Soot's Class-Hierarchy analysis.
- Operations on the string types are translated into appropriate function symbols
depending on the non-string arguments to the operation. A constant
analysis is used to infer the values of these arguments whereever possible in
order to produce a precise approximation.
- Conversions from primitive types to string are modeled by a regular set describing
the possible string values that such a conversion can result in.
- Implicit conversions from reference types to string are translated into a call
to the appropriate toString method. If the intra-procedural nullness analysis provided by Soot
determines that the converted value might be null, the string "
null
" is added as an extra
possibility.
- Any value that could originate from outside the known program is modeled
as the set of all strings. If a
StringBuffer
, StringBuilder
,
or String
array value escapes into
unknown code, it is marked as escaping at that point in the program by a
special escape construct in the IR.
This code may be used under the terms of the
GNU General Public
License.
@author Anders Møller <amoeller@cs.au.dk>
@author Aske Simon Christensen <aske@cs.au.dk>
@author Asger Feldthaus <asf@cs.au.dk>