[Soot-list] Split units in Jimple / missing equals-implementation

[Chris Pickett]

John Jorgensen wrote:
>>>>>>"eric.bodden" == Eric Bodden <eric.bodden at mail.mcgill.ca> writes:
> 
> 
>     eric.bodden> This week I implemented a "must reaching
>     eric.bodden> definitions" analysis, i.e. a definition os
>     eric.bodden> reachable from a use when it is reachable on
>     eric.bodden> *all* paths.  Strangely, this analysis missed
>     eric.bodden> the following case:
> 
>     eric.bodden> 		int j;
>     eric.bodden> 		try {
>     eric.bodden> 			j=3;
>     eric.bodden> 		} catch(Throwable t) {
>     eric.bodden> 			j=4;
>     eric.bodden> 		} finally {
>     eric.bodden> 			j=5;
>     eric.bodden> 		}
> 		
>     eric.bodden> 		//why is j here not 5 FOR SURE?
>     eric.bodden> 		System.out.println(j); //(1)
> 		
> 
>     eric.bodden> Actually, the definition for j has definetely
>     eric.bodden> one unambigous reachable definition:
>     eric.bodden> j=5. However, Soot splits this definition into
>     eric.bodden> multiple ones in the exceptional unit
>     eric.bodden> graph. Since AssignStmt also does not implement
>     eric.bodden> hashcode/equals, the intersection at line (1)
>     eric.bodden> fails, i.e. throws the information j=5 away.
> 
>     eric.bodden> So am I missing something or is there something wrong?
 >
 > [...]
>
> So recognizing that 5 is always stored to i requires
> analyzing the CFG, and it is not the case that all the
> assignments of 5 to i occur at a single definition.

Eric, I think that if you merged (Local,Value) toolkits.scalar.Pair's 
instead of AssignStmt's, treating j=5 on two separate paths as a 
must-reaching def past the merge point might work better.  But I'm not 
sure this is normally considered part of must-reaching definitions, and 
you should probably just worry about treating the input Jimple you are 
given, not the Java source code.

Chris