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

[Patrick Lam]

Doesn't Bruno Dufour know all about this Java EE sort of stuff?

pat

On 01/11/13 00:09, Marc-Andre Laverdiere-Papineau wrote:
> Hello Laurie,
>
> In general, JEE sort of breaks all the rules, as the container (the JEE
> application server) is in charge of all this stuff for you. What that
> means is that the programmer codes against a spec (the javaee-api jar is
> all interfaces and stubs). So, the creation of the object that serves as
> entry point (e.g. a Servlet) is done by a piece of code outside the
> analysis scope. Don't get me started on dependency injection :)
>
> The brutal solution is to put the whole container in the scope - but
> that's near to 100 mb of jars - that's way too impractical.
>
> The other solution is like what you suggested, a synthetic main. A
> problem is that it complicates the API - we need two entry point
> accessors now - one for the 'real' entry points, and another for
> starting the call graph construction algorithm - I can foresee people
> mixing the two and complaining about bugs in soot in this mailing list
> ;) And this synthetic main needs to find the possible types - the target
> class and its subclasses.
>
> I envision something that would work in a single run - that is why I
> coded entry point detectors. I am not sure that this synthetic main
> stuff would work in a single run (if so, I want to know how!)
>
>   From what I had in the exchange with Bernhard, the problem is that we
> are not always sure what is the type of<this>. And that also means that
> we aren't sure what the calls are going to be like - to this class or a
> subclass' override?
>
> So, in some cases, this lack of information is not a problem - we may
> not have subclasses. Or, if there are subclasses, we may go for a
> conservative estimate and have the call graph possibly call the same
> class or the subclasses' overrides.
>
>
> P.S.
> This could be a nice, self-contained and interesting summer project for
> interns - any takers? :)
>
> Regards,
>
> Marc-André Laverdière-Papineau
> Doctorant - PhD Candidate
>
> On 13-01-11 09:15 AM, Laurie Hendren wrote:
>> 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