[Soot-list] Generating invalid code
Marc Hull (Imperial College)
mfh02 at doc.ic.ac.uk
Fri Feb 10 04:23:15 EST 2006
mbatch at cs.mcgill.ca wrote:
> Marc,
>
> I think what you want is a ThisRef:
>
> ThisRef thisRef = new ThisRef(method.getDeclaringClass().getType());
>
> I then do something like this:
>
> Local thisLocal = Jimple.v().newLocal("ths", thisRef.getType());
> locals.add(thisLocal);
>
> units.add(Jimple.v().newIdentityStmt(thisLocal,
> Jimple.v().newThisRef((RefType)thisRef.getType())));
>
>
I tried out these changes exactly as above, but it still seemed to
generate the same code. I did notice in the jimple code that the method
I am altering already has a local tied to 'this'; does Soot/Jimple
disallow having multiple locals tied to the same thing? It also looked
like this local was always present in every method, even if the method
didn't access it; if this is the case, I should be able to use
body.getThisLocal() always whenever I need the 'this' pointer. This does
seem to generate some unusual jimple code, since the IdentityStmt
appears after the code that uses it:
test.A r0;
java.io.PrintStream $r1;
java.lang.String $r2;
uk.ac.ic.doc.cuXca.persistence.IDataRow a1;
uk.ac.ic.doc.cuXca.prototypes.soot.PersistenceManager a2;
// My inserted code (uses r0):
a2 = staticinvoke
<uk.ac.ic.doc.cuXca.prototypes.soot.PersistenceManager:
uk.ac.ic.doc.cuXca.prototypes.soot.PersistenceManager
getFromStaticStore(int)>(0);
virtualinvoke
a2.<uk.ac.ic.doc.cuXca.prototypes.soot.PersistenceManager: void
loadObjectFields(java.lang.Object,java.lang.Class,java.lang.String[])>(r0,
null, null);
// Original code (defines r0):
r0 := @this: test.A;
$r1 = <java.lang.System: java.io.PrintStream out>;
virtualinvoke $r1.<java.io.PrintStream: void
println(java.lang.String)>("Called A.getName()");
$r2 = r0.<test.A: java.lang.String name>;
return $r2;
Fortunately this doesn't seem to affect the translation from jimple to
bytecode, so everything works ok for now!
Thanks for the help,
Marc
More information about the Soot-list
mailing list