[Soot-list] duplicate subgraphs in CFG

[Eric Bodden]

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/