[Soot-list] Transform of call sites

[Hal Hildebrand]

So I got some quality time with this problem last night and came up with the following (high level):


       Iterator statements = body.getUnits().snapshotIterator();
       while (statements.hasNext()) {
           Stmt stmt = (Stmt) statements.next(); 
           if (stmt instanceof InvokeStmt) {
	
               ...  Case A

           } else if (stmt instanceof AssignStmt) {
               AssignStmt assign = (AssignStmt) stmt;
               if (assign.containsInvokeExpr()) {

		    ... Case B

               }
           } else if (stmt.containsInvokeExpr()) {

		... Case C

           }


In both case A and B, the original stmt is my wrapped target.  Only in case C is the transformation performed:


               ValueBox invocation = stmt.getInvokeExprBox();
               InvokeExpr expr = (InvokeExpr) invocation.getValue();
               Local synthesized = newLocal(UUID.randomUUID().toString(), expr.getType(), body);
               Unit invocationUnit = Jimple.v().newAssignStmt(synthesized, expr);
               body.getUnits().insertBefore(invocationUnit, stmt);
               invocation.setValue(synthesized);

However, I have yet to be able to devise a test case that actually creates case C.  As I suspected, the Jimple form of the method has locals for every method call, using an assignment statement; the local is then used as the argument or target of a further statement.  Consequently, my question is whether case C can *ever* occur (excluding case A and B, of course), and under what circumstances.  If it can occur, does someone have an example fragment of Java which will produce a Jimple body from which I can create a test case?

Again, thanks for all the help.

On Jul 27, 2010, at 8:25 AM, Hal Hildebrand wrote:

> On Jul 27, 2010, at 12:56 AM, Eric Bodden wrote:
> 
>>>      if (stmt instanceof InvokeExpr) {
>> 
>> That won't work: a stmt is never an expression. It only sometimes
>> *has* an expression.
> 
> That clause shoud be if (stmt instanceof InvokeStmt), correct?  
> 
>> Also, stmt.containsInvokeExpr() can return true
>> for both an InvokeStmt and an AssignStmt...
> 
> The former should be taken care of by the corrected branch above, if I'm not mistaken.  The worst case of the latter is an additional assignment of the form:
> 
> 	x = someMethodInvoke;
> 	y = x;
> 
> Which should come out in the wash, right?
> 
> Sorry, this isn't my day job so I haven't had the time to spend on this that I'd like.  I'm now putting the scenario testing in place to see if my transformation theories are correct, which should help me progress faster.  Appreciate all the help.