[Soot-list] Question on the DEF/USE analysis

[John Jorgensen]

    jorgnsn> if you are using soot from the command line, I think
    jorgnsn> you can just use the "-omit-excepting-unit-edges" command
    jorgnsn> line option (or more likely "-trim-cfgs", which implies
    jorgnsn> "-omit-excepting-unit-edges") to turn off
    jorgnsn> alwaysAddSelfEdges, without having to replace the
    jorgnsn> ExceptionalUnitGraph implementation.

    cregut> In fact, no, in the code of ExceptionalUnitGraph, you have: 
    cregut>  boolean alwaysAddSelfEdges = ((! omitExceptingUnitEdges) ||
    cregut>                       mightHaveSideEffects(thrower));
    cregut> So you have to have both omitExceptingUnitEdges to true and
    cregut> mightHaveSideEffects to false to get rid of the
    cregut> behaviour.

Right, I wasn't paying close enough attention; in the context of
the Def/Use analysis, you don't care about the side effects, 
only about the assignments.

    cregut> If we have a jimple instruction
    cregut>  x = m(...), we have
    cregut> we have at least two JVM instructions. 
    cregut> - One for the invoke that may fail because of m :
    cregut> - One that modifies x that can only fail if it has
    cregut>   its own problems 

You could see this as a weakness of Soot's intermediate
representations; they don't provide a way to separate the
invocation of a method from the assignment of its result.

Depending on the order in which the analyses are performed (I'm
too lazy to check what the order is myself), it's possible that
you could simulate that separation by generating an extra Jimple
assignment of the results of method calls, turning something like
this:

 $i0 = o.method(arg0)

into this

 $i0temp = o.method(arg0)
 $i0 = $iotemp

Then if your Use/Def analysis could build a CFG using this idiom
before copy propagation optimizes the extra assignment away, you
might be able to get what you want (no edge to the catch from the
final assignment to $i0) without ignoring side effects (not that
I can think of any particular disadvantage to ignoring side
effects if you're only analyzing the definitions of local variables).

    cregut> There is a last question, the JVM and the Dalvik VM
    cregut> distinguishes "Throwable" and "<any>".  There can be
    cregut> a handler for both even if according to the VM
    cregut> specification, I do not see what can be between any
    cregut> and Throwable which is the ancestor of both Errors
    cregut> and Exceptions.

I suspect (but do not know for certain) that the apparent
distinction between "<any>" and "Throwable" is just an
artifact of the class file representation (see section 4.7.3 of
the JVM specification).

The class file has an exception table structure to represent try
blocks and catch clauses.  My guess is that "<any>" appears as
the catch parameter type when the exception table entry's
catch_type is set to 0 (which means all exceptions according to
the JVM spec) and that "Throwable" appears as the catch parameter
type when the entry's catch_type is a constant pool reference to
"Throwable" (which also means all exceptions, by my reading of
section 2.13.3 of the JVM spec).  I think they amount to the same
thing, just represented differently.