[Soot-list] Duplicating Locals!!

[Bodden, Eric]

I think the problem is that local-variable types are not preserved in bytecode, which is why Soot infers them using the usages of the respective variables.
In some cases this requires splitting of variables, which you observe here. Am I right to assume that you are processing bytecode, not source code?

With the current variables that Jimple generates, what exactly is the problem for you? Simply having more variables should not affect the correctness of your analysis.

Eric


On 05.03.2014, at 03:43, M Alsob <m99m20 at hotmail.com> wrote:

> Hi,,
> this is a method in the test java source:
> public static void fun(int x)
> 
> {
> 
> 
> x--;
> 
> int option1 = x%3;
> 
> int option2 = x%2;
> 
> switch ( option1 )
> 
> {
> 
> case 1 :
> 
> switch ( option2 )
> 
> {
> 
> case 1 : System.out.println("Option1, Option1");
> 
> break;
> 
> case 0 : System.out.println("Option1, Option2");
> 
> break;
> 
> default : System.out.println("Option1, Unknown");
> 
> }
> 
> break;
> 
> case 2 : System.out.println("Option2, No Nested Switch");
> 
> break;
> 
> default : System.out.println("Unknown Case");
> 
> }
> 
> 
> System.out.println(x);
> 
> return;
> 
> }
> 
> the jimple body corresponding to it:
> /*8*/
> 
> public static void fun(int)
> 
> {
> 
> int x, option1, option2, x;
> 
> java.io.PrintStream $r0;
> 
> 
> x := @parameter0: int;
> 
> /*9*/
> 
> x = x + -1;
> 
> /*9*/
> 
> option1 = x % 3;
> 
> /*10*/
> 
> /*10*/
> 
> option2 = x % 2;
> 
> /*11*/
> 
> /*11*/
> 
> tableswitch(option1)
> 
> {
> 
> case 1: goto label0;
> 
> case 2: goto label4;
> 
> default: goto label5;
> 
> };
> 
> /*12*/
> 
> 
> label0:
> 
> tableswitch(option2)
> 
> {
> 
> case 0: goto label2;
> 
> case 1: goto label1;
> 
> default: goto label3;
> 
> };
> 
> /*15*/
> 
> 
> label1:
> 
> $r0 = <java.lang.System: java.io.PrintStream out>;
> 
> /*17*/
> 
> virtualinvoke $r0.<java.io.PrintStream: void println(java.lang.String)>("Option1, Option1");
> 
> /*17*/
> 
> goto label6;
> 
> /*18*/
> 
> 
> label2:
> 
> $r0 = <java.lang.System: java.io.PrintStream out>;
> 
> /*19*/
> 
> virtualinvoke $r0.<java.io.PrintStream: void println(java.lang.String)>("Option1, Option2");
> 
> /*19*/
> 
> goto label6;
> 
> /*20*/
> 
> 
> label3:
> 
> $r0 = <java.lang.System: java.io.PrintStream out>;
> 
> /*21*/
> 
> virtualinvoke $r0.<java.io.PrintStream: void println(java.lang.String)>("Option1, Unknown");
> 
> /*21*/
> 
> goto label6;
> 
> /*23*/
> 
> 
> label4:
> 
> $r0 = <java.lang.System: java.io.PrintStream out>;
> 
> /*24*/
> 
> virtualinvoke $r0.<java.io.PrintStream: void println(java.lang.String)>("Option2, No Nested Switch");
> 
> /*24*/
> 
> goto label6;
> 
> /*25*/
> 
> 
> label5:
> 
> $r0 = <java.lang.System: java.io.PrintStream out>;
> 
> /*26*/
> 
> virtualinvoke $r0.<java.io.PrintStream: void println(java.lang.String)>("Unknown Case");
> 
> /*26*/
> 
> 
> label6:
> 
> $r0 = <java.lang.System: java.io.PrintStream out>;
> 
> /*29*/
> 
> virtualinvoke $r0.<java.io.PrintStream: void println(int)>(x);
> 
> /*29*/
> 
> return;
> 
> /*30*/
> 
> }
> 
> for the main method, we the following vars:
> 
> int w = 5, y, x, z;
> 
> the corresponding vars in jimple body:
> 
> byte w, y;
> 
> int x, z, x, w, $i0;
> 
> java.lang.StringBuilder $r0;
> 
> boolean $z0, y;
> 
> As you can see some vars in jimple declared twice -in the same scope- either of the same data type( such as x) or of different data types( such as w, and y)..
> 
> this issue affects the both liveness and reaching definition analysis of the source code!!
> 
> is there a way to force jimple transformation to stick to the original data types as declared in the source code??
> 
> Thank you,,
> 
> 
> 
> Sent from Windows Mail
> 
> From: Bodden, Eric
> Sent: ‎Monday‎, ‎March‎ ‎3‎, ‎2014 ‎8‎:‎02‎ ‎AM
> To: Modhi Alsobeihy
> Cc: Steven Arzt, soot-list at sable.mcgill.ca
> 
> Hello.
> 
> What does the Jimple body look like for this method?
> In general it is not uncommon for Jimple bodies to have multiple Locals with the same name. This can even happen in Java due to scoping rules of blocks.
> 
> Eric

--
Prof. Eric Bodden, Ph.D., http://sse.ec-spride.de/ http://bodden.de/
Head of Secure Software Engineering  at Fraunhofer SIT, TU Darmstadt and EC SPRIDE
Tel: +49 6151 16-75422    Fax: +49 6151 16-72051
Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20140305/7c089a62/attachment.bin