[Soot-list] Issue with trap generation in Jimple

[Eric Bodden]

Thanks a lot John, for the explanation as well as for the considerate
implementation!

I saw in the code that you specifically check whether an instruction
can have side effects. That makes sense.

The code now works good enough for me, but you are right, ultimately
we would want something even different, I guess. Specifically even in
the case of a side effect we definitely know that $u1 cannot have been
assigned anything if an exception is thrown. Nevertheless, we don't
know anything about the global state. I wonder whether there's another
paper lurking there... I just cannot think of a really perfect
treatment of such issues for now.

Eric


On 13 June 2012 22:35, John Jorgensen <jorgnsn at cs.uregina.ca> wrote:
>>>>>> "eric.bodden" == Eric Bodden <eric.bodden at ec-spride.de> writes:
>
>    eric.bodden> I actually got this resolved. It turns
>    eric.bodden> out that ExceptionalUnitGraph already has a
>    eric.bodden> boolean argument to its constructor that let's
>    eric.bodden> one control the semantics exactly for this
>    eric.bodden> case. I actually wonder whether we should not
>    eric.bodden> change the default, though.
>
> First, thanks for giving my ego a boost (I'm the one who included
> the omitExceptingUnitEdges parameter in the ExceptionalUnitGraph
> constructor some nine years ago).
>
> Second, though my knowledge of Soot is rusty enough that I'm not
> confident about what I'm about to say, I'm not sure that
> omitExceptingUnitEdges will solve your typing problem in the
> most general case.
>
> Let's change the assignment in your example so that its RHS is a
> method invocation (one of the consequences of my stale knowledge
> of soot is that I'm not sure such jimple can actually be
> generated from real bytecode):
>
>     label5:
>        $u0 = someMethodOrOther();
>        return $u0;
>
>     label6:
>        $u1 := @caughtexception;
>        exitmonitor $u0;
>        throw $u1;
>
>        catch java.lang.Throwable from label2 to label5 with label6;
>
> Now the assignment to $u0 has potential side effects, so even if
> omitExceptingUnitEdges is true, there will be an exceptional edge
> from the assignment itself to the handler (since the
> ExceptionalUnitGraph constructor knows nothing about what
> someMethodOrOther() does, it conservatively assumes that it might
> modify something that the exception handler cares about).
>
> There's more on this issue in section 2.4 (and especially 2.4.1)
> of Sable technical report 2003-3.
>
> --
> John Jorgensen    <jorgnsn at cs.uregina.ca>    306.337.2344



-- 
Eric Bodden, Ph.D., http://bodden.de/
Head of Secure Software Engineering Group at EC SPRIDE
Principal Investigator in Secure Services at CASED
Tel: +49 6151 16-75422    Fax: +49 6151 16-72051
Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt