[Soot-list] Call Graph issues and advice needed

[Rohan Padhye]

Dear Henndher,

You might also want to take a look at Marc-André's suggestion of using 
a switch-case in the stub main to simulate unordered entry points:

main(){
   switch(...) {
     case 1: e1(); break;
     case 2: e2(); break;
   }
}

This might allow you to run just a single IFDS solution to get the 
merged results directly.

Note: Marc-André originally suggested a switch-case loop, although I 
think the same effect can be achieved without the loop as you just want 
to simulate multiple distinct entry points.

Regards,
Rohan

On 2013-04-27 19:53, Henddher Pedroza wrote:
> Thank you Bernhard,
>
> Rohan Padhye noted this:
>
> main() {
>    e1();
>    e2();
> }
>
> e1() {
>    x = 10;
> }
>
> e2() {
>    use x;
> }
>
> If you use a stub main then your analysis might conclude that x = 10
> is constant at e2(), but that is not the case if the program starts 
> at
> e2(). In IFDS terms, you really want results of thread starting at e2
> to compute reachability from the zero node only, not all nodes that
> are true at the exit of the thread starting at e1.
>
> You would probably be better off performing multiple IFDS solutions,
> one for each entry point, and then merging results for each program
> point across all such instances if you want to do some optimizations.
>
> If I understood correctly, one would need to generate entry points
> per thread and compute IFDS on each set.
>
> Thanks again.
>
> On Apr 27, 2013, at 9:06 AM, Bernhard Berger <berber at tzi.de> wrote:
>
>> Hi,
>>
>>> As for the non-static entry point stuff, I'm going to ask Bernhard 
>>> to
>>> elaborate on that, because he dealt with it a whole lot more than I 
>>> did.
>>> IIRC it was because of the this pointer.
>>>
>>> My guess is that you could patch Spark to deal with it by using CHA 
>>> to
>>> resolve the this pointer whenever you have a non-static entry 
>>> point.
>>> After all, you don't have any extra information at that point to 
>>> know
>>> what you're pointing to…
>>
>> a year or two ago I tried to use the entry point mechanism to get a 
>> call graph of android components. I used probe to dump and check the 
>> results of the cg construction and observed that calls where missing. 
>> AFAIR there were entry methods that called another method within the 
>> class (this.foobar()) and they were missing. Furthermore there were 
>> problems with calls on the parameters. I never debugged it but I 
>> inferred that the reason is that there is information missing on the 
>> concrete type of this and the parameters. At this point I switched to 
>> entry point generation (creating a dummy main, creating the objects 
>> and parameters and call the methods).
>>
>> Regards,
>> Bernhard
>>
>> _______________________________________________
>> Soot-list mailing list
>> Soot-list at sable.mcgill.ca
>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>
>
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list

-- 
Regards,
Rohan Padhye