[Soot-list] Identify virtual-call targets and library callee

[Haipeng Cai]

Thanks again, Marc-Andre.

Actually I am calling soot.Main.main after a customized transformation
(extending SceneTransformer and implementing its abstract method
internalTranform) during the whole-jimple transformation pack (wjtp).
 Right now I already started using a makeshift to temporarily meet my
analysis needs regardless of the incomplete callgraph problem I had. Later,
I guess I would try something further along the other possibility you
mentioned.

I assume that you mean Java EE by JEE, which I am not working on. I
appreciate your inputs.

Regards,



On Sat, Jul 26, 2014 at 11:17 AM, Marc-André Laverdière <
marc-andre.laverdiere-papineau at polymtl.ca> wrote:

> Hello Haipen,
>
> RTA is a more conservative analysis than Spark's own analysis, so I
> don't think this is an issue.
>
> Are you using the soot main? Normally, you don't get to specify the PTA
> for the call graph builder - so I'm guessing that you decided without.
> I'd encourage you to try again using the Soot main and see if that
> solves your problem.
>
> Another possibility is that the missing edges are targets to methods
> that are phantom. I suggest that you create a simple SceneTransformer to
> put in the WJTP phase and that goes through the reachable methods and
> checks for missing edges. Then, for each missing edge, check the phantom
> flag in the declaring class.
>
> By the way, are you working on JEE?
>
> Regards,
>
> Marc-André Laverdière-Papineau
> Doctorant - PhD Candidate
>
> On 07/26/2014 12:39 AM, Haipeng Cai wrote:
> > Thank you for your reply, Marc-Andre.
> >
> > Yes I am using Spark with option "-p cg.spark verbose:false,
> > on-fly-cg:true,rta:true", and I am providing all the jars in the Soot
> > classpath except for Soot itself and I did have option "-allowphantom".
> >
> > Also, when constructing the call graph, I used the default p2 analysis
> > (Scene.v().getPointsToAnalysis()) for the CallgraphBuilder.
> >
> > Is there something wrong in my settings that caused missing outgoing
> > edges for a call site in the graph?
> >
> > Best,
> >
> >
> > On Fri, Jul 25, 2014 at 11:31 AM, Marc-André Laverdière
> > <marc-andre.laverdiere-papineau at polymtl.ca
> > <mailto:marc-andre.laverdiere-papineau at polymtl.ca>> wrote:
> >
> >     Hi Haipeng,
> >
> >     Call graph construction is a difficult beast. Soot has a lot of
> options
> >     that may also impact the call graph construction algorithm. It also
> >     affects the class hierarchy, which is also going to affect the call
> >     graph.
> >
> >     First, are you using Spark? Which settings?
> >     Everything besides CHA relies on 'new' statements in the program to
> >     determine which type could a given variable have. So if your
> application
> >     has things like dependency injection, then your life is even harder.
> >
> >     Are you using phantom classes? No bodies for excluded? Are you
> providing
> >     all the jars in the Soot classpath? These things will affect the
> >     outcome.
> >
> >     I've been working on JEE applications and I resort to a lot of
> tricks to
> >     try to make the call graph smaller. This results in a lot of missing
> >     edges, which need to be compensated somehow. I've generally
> compensated
> >     by using the declared SootMethod in the InvokeExpr but that's not
> >     perfect. Flowdroid is doing the same BTW.
> >
> >     Regards,
> >
> >     Marc-André Laverdière-Papineau
> >     Doctorant - PhD Candidate
> >
> >     On 07/24/2014 08:14 PM, Haipeng Cai wrote:
> >     > Hi All,
> >     >
> >     > I am doing a static interprocedural dependence analysis with Soot
> for
> >     > Java programs and having two difficulties:
> >     >
> >     > 1. How do I safely identify all possible callees at a call site,
> >     > especially virtual call site?
> >     >
> >     > 2. How should I discern, among all the callees identified above,
> >     library
> >     > callees from application callees?
> >     >
> >     > I have tried the CallGraph class, which seems to be quite
> >     incomplete; I
> >     > also noticed that there is a method "IsJDKLibraryCall" in
> SootMethod
> >     > class, which only tells JDK library calls from others, though.
> >     >
> >     > Any thoughts and advises are appreciated.
> >     > Thanks,
> >     >
> >     > _______________________________________________
> >     > Soot-list mailing list
> >     > Soot-list at CS.McGill.CA <mailto:Soot-list at CS.McGill.CA>
> >     <mailto:Soot-list at CS.McGill.CA <mailto:Soot-list at CS.McGill.CA>>
> >     > https://mailman.CS.McGill.CA/mailman/listinfo/soot-list
> >     > <https://mailman.cs.mcgill.ca/mailman/listinfo/soot-list>
> >     >
> >     >
> >     > _______________________________________________
> >     > Soot-list mailing list
> >     > Soot-list at CS.McGill.CA <mailto:Soot-list at CS.McGill.CA>
> >     > https://mailman.CS.McGill.CA/mailman/listinfo/soot-list
> >     >
> >     _______________________________________________
> >     Soot-list mailing list
> >     Soot-list at CS.McGill.CA <mailto:Soot-list at CS.McGill.CA>
> >     https://mailman.CS.McGill.CA/mailman/listinfo/soot-list
> >
> >
> _______________________________________________
> Soot-list mailing list
> Soot-list at CS.McGill.CA
> https://mailman.CS.McGill.CA/mailman/listinfo/soot-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20140726/ec81d2c4/attachment.html