[Soot-list] duplicate subgraphs in CFG

[Eric Bodden]

Fair enough. Just to let you know: In most cases you actually may want
to use an ExceptionalUnitGraph, not a BriefUnitGraph, as the latter
omit crucial exceptional flow.

Eric

2008/12/4  <hsadat at gmail.com>:
> No worries. Thanks for looking into it.
>
> So far, I haven't really been doing anything with these CFGs; just trying to
> understand the various forms they take in soot. So, I really can't tell if
> this is going to cause any problems. Hopefully, none :)
>
> Thanks again.
>
> --Hossein
>
> On 4-Dec-08, at 9:16 PM, Eric Bodden wrote:
>
>> I am sorry but I am not sure why this happens. Interesting
>> observation... Anyway, is that a problem for you?
>>
>> Eric
>>
>> 2008/12/4  <hsadat at gmail.com>:
>>>
>>> Thanks Eric.
>>>
>>> You're right. Actually, I was partly confused because I had no
>>> "throw"-ending path in the CFG; but after I scrolled to the right, it was
>>> right there! (I'm using brief CFG, so, I get a forest.)
>>>
>>> Now, what you said explains the duplication for "normal" and
>>> "exceptional"
>>> paths; however, the subgraph is also duplicated for two different paths
>>> that
>>> both merge into normal return. Here is my example (see the attached png
>>> for
>>> the CFG):
>>>
>>> try{
>>>      f();
>>> }
>>> catch(IOException)
>>> {
>>>      g();
>>> }
>>> finally{
>>>      h();
>>> }
>>>
>>> Please see the attached CFG.
>>>
>>> So, the flow from catch (handled exception) and try (normal flow) both
>>> merge
>>> into finally block. Therefore, there's no need for duplicate h() nodes
>>> for
>>> these two paths. Am I missing another thing? (Sorry if I'm asking dumb
>>> questions ...)
>>>
>>> --Hossein
>>>
>>>
>>>
>>>
>>>
>>> On 4-Dec-08, at 5:43 PM, Eric Bodden wrote:
>>>
>>>> The duplication is simply to implement the correct semantics. If you
>>>> have...
>>>>
>>>> try{
>>>> foo();
>>>> } finally {
>>>> bar();
>>>> }
>>>>
>>>> ... then you need something like ...
>>>>
>>>> label1:
>>>> foo();
>>>> label2:
>>>> bar();
>>>> return;
>>>> label3:
>>>> e = @caughtexception;
>>>> bar();
>>>> throw e;
>>>>
>>>> trap Throwable from label1 to label2 with label3;
>>>>
>>>> ... on the Jimple level because you want to execute bar() *regardless*
>>>> of the exception being thrown, but you obviously want to return *or*
>>>> throw depending on whether an exception was raised within the try
>>>> block. The label/location of the copied block therefore sort of
>>>> encodes the information "exception" or "no exception".
>>>>
>>>> Eric
>>>>
>>>>
>>>>
>>>> 2008/12/4  <hsadat at gmail.com>:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I was looking at the CFGs built in interactive mode using Soot Eclipse
>>>>> plugin and noticed that there are some duplicate subgraphs;
>>>>> specifically,
>>>>> the subgraph corresponding to "finally" block is repeated, one for the
>>>>> path
>>>>> from the end of the catch block and the other for the path from end of
>>>>> try
>>>>> block. Has anyone encountered this? and is there an explanation behind
>>>>> it?
>>>>>
>>>>> I tried to think of possible reasons for duplicating; because I know in
>>>>> the
>>>>> analysis context, some of the nodes are created to make later
>>>>> analysis/transformation easier (e.g. "nop" nodes).
>>>>>
>>>>> So, any clues?
>>>>>
>>>>> Thanks
>>>>>
>>>>> --Hossein
>>>>> _______________________________________________
>>>>> Soot-list mailing list
>>>>> Soot-list at sable.mcgill.ca
>>>>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Eric Bodden
>>>> Sable Research Group, McGill University, Montréal, Canada
>>>> Got an interesting job offer? http://www.bodden.de/hire-me/
>>>
>>>
>>>
>>
>>
>>
>> --
>> Eric Bodden
>> Sable Research Group, McGill University, Montréal, Canada
>> Got an interesting job offer? http://www.bodden.de/hire-me/
>
>



-- 
Eric Bodden
Sable Research Group, McGill University, Montréal, Canada
Got an interesting job offer? http://www.bodden.de/hire-me/