[Soot-list] Converting reflection code to static code
ASHISH MISHRA
ashish123.mishragkp at gmail.com
Thu Feb 7 18:39:40 EST 2013
Hi Eric,
Sorry , I think, I didn't put the problem correctly. The TamiFlex paper
reports that the static inlining has been done by Livshits, Whaley and Lam.
I wish to implement the same analysis with some extension using soot and I
was confused where to implement my transforms and how to proceed.
since their analysis is not publicly available , I wish to use soot to
develop such an analysis. My Problem was that what phase should I add my
Transforms.
Since I am trying to generate a precise reflection aware call graph ,
Should I add a transform to cg phase .
Or wjtp , or wjop. But now after dwelling a little further I think I
should try some thing like this-
The whole program analysis like pointer analysis and String analysis should
be done by adding a transform to wjtp phase.
Once i have this analysis result , i should add a wjop transform, to inline
reflective calls resolved using earlier analysis results.
and finally generate a Call graph in a second run of the soot on modified
or enriched jimple code.
On Fri, Feb 8, 2013 at 3:54 AM, Eric Bodden <eric.bodden at ec-spride.de>wrote:
> Hello.
>
> I was just wondering... have you looked at the related work section of
> the TamiFlex paper? Actually the static inlining has already been done
> by others and you may want to look at their work.
>
> Also JSA should be quite interesting to you:
> http://www.brics.dk/JSA/
>
> Eric
>
> On 7 February 2013 23:05, ASHISH MISHRA <ashish123.mishragkp at gmail.com>
> wrote:
> > Namaste Marc-Andre,
> >
> > Thanks a lot,
> > I think you clearly got my problem, :)
> >
> >
> > "The most tempting answer.... " Thanks for the insight , I was thinking
> on
> > similar lines and your suggestion looks really promising. I will try
> this
> > out and will come to the group if in some trouble or with some new
> findings.
> >
> > regards
> > Ashish
> >
> >
> > On Fri, Feb 8, 2013 at 2:52 AM, Marc-Andre Laverdiere-Papineau
> > <marc-andre.laverdiere-papineau at polymtl.ca> wrote:
> >>
> >> Namaste Ashish,
> >>
> >>
> >> Since I am not fully understanding your question, my answer could be
> >> missing the mark. Don't hesitate to ask point out if that is the case.
> >>
> >> 1) The phase
> >> You 'cannot' modify the phase cg, so that one is out question. Of
> >> course, you can always do what you want with the source code, but lets
> >> just say it is not really recommended ;)
> >>
> >> By default wjop is disabled, so that's not the best option.
> >>
> >> So if you want to do something before the call graph is constructed, go
> >> for wjpp, otherwise use wjtp.
> >>
> >> 2)
> >> The most tempting answer for me is to tell you to do two runs of soot.
> >> You can output the results of the first analysis in Jimple format, so
> >> the next run would be faster.
> >>
> >> On the first run, you would take the spark output in wjtp and do your
> >> analysis and store results on the disk. (If you have any run-time
> >> information you want to put in, you could do that there, or in wjpp).
> >>
> >> On the second run, you would do the transformations in wjpp and let
> >> Spark take it from there.
> >>
> >> If the results are good, then a closer integration in soot (like in the
> >> cg phase) would make sense :)
> >>
> >> 3) Precise interprocedural analysis without CG
> >> Well, yes and no. You can determine call targets locally, but your
> >> precision may not be super good. Java programs love to pass objects all
> >> over the place, so the type can be hard to guess intraprocedurally. You
> >> can try, and fall back on CHA if you don't have local information.
> >>
> >> Tripp et al. published a paper on their Andromeda system that does away
> >> with a global call graph construction - it could be interesting for you.
> >>
> >> I hope it helps.
> >>
> >> Regards,
> >>
> >> Marc-André Laverdière-Papineau
> >> Doctorant - PhD Candidate
> >>
> >> On 13-02-07 03:47 PM, ASHISH MISHRA wrote:
> >> > Hi all,
> >> >
> >> > I understand how to use tamiflex to handle reflection using soot. i
> wish
> >> > to solve the problem(To some extent , since, exact solution could not
> be
> >> > computed.) using String analysis, pointer analysis and some other
> static
> >> > ways. My main concerns is -
> >> >
> >> > Suppose I have a code fragment say its original Program P
> >> >
> >> > //
> >> > 4String str= "someclassname"
> >> > 5Class clazz = Class.forNmae(str);
> >> >
> >> > 6Method mt=clazz.getMethod("execute", null);
> >> > 7 mt.invoke(o , null);
> >> >
> >> > //some other code.
> >> >
> >> > I can analyze the argument passed to the dynamic class loading at
> line 5
> >> > using the String analysis and if its is a Constant string or it can be
> >> > tracked via some other means I can enrich this program P to some thing
> >> > like
> >> >
> >> > 4String str= "someclassname"
> >> > 5Class clazz = Class.forNmae(str);
> >> >
> >> > 6Method mt=clazz.getMethod("execute", null);
> >> > 7 mt.invoke(o , null);
> >> >
> >> > someclass sc = new someclass();
> >> > sc.execute();
> >> >
> >> > //some other code. say p'
> >> >
> >> > And finally run Call Graph construction algorithm on P'
> >> >
> >> > My first question is -
> >> >
> >> > I am confused about where to add my transformation-
> >> > 1)wjop - looks most promising ,as I am optimizing the source
> >> > 2)cg
> >> > 3wjtp
> >> >
> >> > Secondly
> >> >
> >> > Do I need to add two different transformations ,
> >> > one to generate an On the fly Call graph with pointer analysis and
> >> > String analysis
> >> > and then apply the transformation from P to P' and then again
> generate a
> >> > Call graph again. i need a precise Call graph of whole application
> with
> >> > reflection information added by a side analysis like String , pointer
> >> > and other static analysis.
> >> >
> >> > Is its possible to get a precise inter procedural dataflow analysis
> >> > independent of Call graph construction. I feel its not possible as
> they
> >> > both are interlinked.
> >> >
> >> > Please help me on this.
> >> >
> >> > --
> >> > Regards,
> >> > Ashish Mishra
> >> > Graduate Student,
> >> > Computer Science and Automation Department,IISc
> >> > Cell : +91-9611194714
> >> > Mailto : ashishmishra at csa.iisc.ernet.in
> >> > <mailto:ashishmishra at csa.iisc.ernet.in>
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > 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,
> > Ashish Mishra
> > Graduate Student,
> > Computer Science and Automation Department,IISc
> > Cell : +91-9611194714
> > Mailto : ashishmishra at csa.iisc.ernet.in
> >
> >
> > _______________________________________________
> > Soot-list mailing list
> > Soot-list at sable.mcgill.ca
> > http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
> >
>
>
>
> --
> Eric Bodden, Ph.D., http://sse.ec-spride.de/ http://bodden.de/
> Head of Secure Software Engineering Group at EC SPRIDE
> Tel: +49 6151 16-75422 Fax: +49 6151 16-72051
> Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt
>
--
Regards,
Ashish Mishra
Graduate Student,
Computer Science and Automation Department,IISc
Cell : +91-9611194714
Mailto : ashishmishra at csa.iisc.ernet.in
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20130208/1ad125be/attachment.html
More information about the Soot-list
mailing list