[Soot-list] Exception handling

[Patrick Lam]

(cc'd to soot-list for archival reasons. The patch I committed yesterday 
causes java.lang.String to fail to jimplify.)

Eric Bodden wrote:
> I was able to reproduce this, at least with abc. Interestingly the
> class in question if not java.lang.String from the input file but from
> the JDK. Don't ask me why ;-)
> 
> Anyway, the method in question is:
> 
>     public boolean contentEquals(StringBuffer sb) {
>         synchronized(sb) {
>             return contentEquals((CharSequence)sb);
>         }
>     }
> 
> Attached I have the two Baf bodies for this method before and after
> applying your patch. As you can see, the version "after" seems to
> contain a spurious "store.r r0;" right after the return.
> 
> Does that give you an idea of what could be going wrong?

Yeah. I committed another patch which logically makes sense, but I am 
not really not familiar with this part of the code. It actually 
simplifies the code by removing a HashMap and replacing it with a HashSet.

When Soot converts an exception handler in Coffi into Jimple, it inserts 
an IdentityStmt s, e.g. r0 := @caughtexceptionref. Let's say that the 
exception handler starts with Coffi instruction i. Yesterday's patch 
inserts the IdentityStmt s right before code corresponding to i, so that 
it would also be covered by any traps pointing to i (as Sylviu pointed 
out it should).

For some reason, Soot also used to keep a mapping between targets and 
handlers. The target would have been the Jimple statement corresponding 
to i and the handler was statement s. I don't see why that makes sense, 
because we should always use s, so I replaced the map with a set of 
handlers that we've added.

I've done some minimal testing and it seems to work correctly, but 
something weird might happen on other cases.

pat