[Soot-list] Call Graph with non-static entry points?

[Marc-Andre Laverdiere-Papineau]

Hello,

Were you able to make such transformations happen in the same soot run? 
If so, in which phase(s) did you put them?

I think this is going to be a good topic for a blog post... ;)

Marc-André Laverdière-Papineau
Doctorant - PhD Candidate

On 13-01-11 02:13 PM, Eric Bodden wrote:
> Hi all.
>
> We observed the same problem when analyzing Android apps because also
> there some objects like the main Activity objects just "appear from
> nowhere". We solved this by adding an entry-point generator that
> automatically generates stub methods which we then use as entry
> points. Back then I discussed this with Ondrej and he told me this
> would be the easiest way to go about this (the alternative being to
> modify Spark). I think I now agree with Ondrej. It was actually
> relatively easy and another advantage is that if you generate such
> "fake main methods" automatically then you can generate them in such a
> way that they simulate the correct lifecycle of the component you are
> analyzing, e.g., call lifecycle methods such as "start" and "stop" in
> the right order. Flow-sensitive analysis components such as Heros can
> take advantage of that.
>
> Eric
>
> On 11 January 2013 08:36, Bernhard Berger <berber at tzi.de> wrote:
>> Hi,
>>
>> the problem I observed had to do with calls to methods of the same instance. e.g.:
>>
>> void entryPoint(Param entryParameter) {
>>    this.foo();
>> }
>>
>> The call to foo was missing in the resulting call graph. It would be very logical to say that spark has got now information about this and therefore fails to resolve the call. That was the conclusions I made and solved my problem by generating a "correct" main method that generates an instance and respects the lifecycle of the managed object.
>>
>> Bernhard
>>
>> Am 11.01.2013 um 04:45 schrieb Laurie Hendren <hendren at cs.mcgill.ca>:
>>
>>> Hi Marc-Andre,
>>>
>>> I would have to look to see why that would be a problem,  but it may
>>> have to do with needing a concrete object for the receiver.     In fact,
>>> if your entry points are not static, doesn't some method need to create
>>> an object on which it calls your entry point ..
>>>
>>> If so, then wouldn't you just have to create a dummy static method that
>>> creates an object and makes the call,  and then start the call graph
>>> algorithm at the dummy static method?
>>>
>>> Or ... am I misunderstanding your question?
>>>
>>> Laurie
>>>
>>>
>>>
>>> +--------------------------------------------------------------
>>> | Laurie Hendren --- http://www.sable.mcgill.ca/~hendren
>>> | Associate Dean (Academic), Faculty of Science
>>> | Professor, School of Computer Science, McGill University
>>> | New McLAB project:  http://www.sable.mcgill.ca/mclab/
>>> | Also: www.sable.mcgill.ca/soot  www.sable.mcgill.ca/abc
>>> +--------------------------------------------------------------
>>>
>>> On 10/01/2013 10:30 PM, Marc-Andre Laverdiere-Papineau wrote:
>>>> Hello,
>>>>
>>>> Chatting with Bernhard yesterday, he was telling me that there are
>>>> problems with Spark when the entry points are not static.
>>>>
>>>> Since my entry point detection framework is very good at detecting
>>>> non-static things, I am wondering if that is making the framework moot.
>>>>
>>>> Can anyone confirm whether Spark, or call graph constructions algorithms
>>>> in general, have an assumption concerning the type of entry points it is
>>>> dealing with? Or should that be considered as a bug that we'll fix along
>>>> the way?
>>>>
>>>> Regards,
>>>>
>>>
>>> _______________________________________________
>>> 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
>
>
>