[Soot-list] Interpreter for Soot & How to profile edge count for whole program

[Ben Holland]

Oh, I missed your point about library classes. Yea I would just make the
"library" class an "application" class. I've used  -Xbootclasspath before
as well. It's more of an implementation hack at the end of the day. You
might also be able to do some package namespace collision hacks too if you
are interested in just a few classes. I'm not totally sure how Soot will
respond in these cases though. It's not hard to have soot produce/transform
jimple for the rt.jar method, so you could create a new jar and replace it
in your runtime directory or use xbootclasspath. I did something similar
for my https://jreframeworker.com tool (doesn't use Soot, just ASM, but
same idea).

P.S. I noticed that while Soot supports making Jimple for Java 8 the output
Jimple had some runtime issues when it came to lambdas. My group made a fix
for it and I think even submitted something upstream to Soot but I'm not
sure what the status of that is. For proof of concept stuff you might want
to stick to Java 7 especially when dealing with core JDK level classes.

On Sat, Nov 3, 2018 at 4:25 PM Zhou, Tong <tz at gatech.edu> wrote:

> Hi Ben,
>
>
> Thanks for your help! However that doesn't seem to work with the library
> classes. Although it's easy to also instrument the library classes  but so
> far I don't know how to instruct the JVM to use my custom library class
> instead of its default stuff. I am going to try something like
> -Xbootclasspath/p: , that might be able to overwrite the bootloaded
> classes. Thanks a lot!
>
>
> -Tong
> ------------------------------
> *From:* Ben Holland <benjholla at gmail.com>
> *Sent:* Saturday, November 3, 2018 4:52:26 PM
> *To:* Zhou, Tong
> *Cc:* soot-list at cs.mcgill.ca
> *Subject:* Re: [Soot-list] Interpreter for Soot & How to profile edge
> count for whole program
>
> I've built something like this before using Soot and another tool called
> Atlas. The code is public, but not very clean/reliable at this time and
> it's not using an official branch of Soot. Anyway, the idea is relatively
> simple. Soot lets you insert statements before/after statements. You can
> use this to insert counters before each statement in your control flow
> graph. A similar example for counting GOTOs is included with Soot:
> https://github.com/Sable/soot/wiki/Adding-profiling-instructions-to-applications.
> Each edge in a control flow graph is a transition from one node to another
> in the control flow graph, so if you were to track the sequence that nodes
> were visited you could easily correlate that to an edge and keep counters
> for each edge. The trick will be to implement it so it's not tracking too
> much at a time. You only need to the node which node was the previous node
> to infer the edge, so you should only have to track one item at a time,
> otherwise, you will be adding a lot of overhead in your instrumentation.
>
> On Sat, Nov 3, 2018 at 2:30 PM Zhou, Tong <tz at gatech.edu> wrote:
>
> Hi,
>
>
> Is there any existing project that builds an interpreter on top of Jimple
> or Shimple? I am currently trying to profile the dynamical basic block
> counts of a program using an instrumentation-based approach (insert code
> that increments a counter) but couldn't find a way instrument the library
> classes (java.lang.xxx etc). So I was thinking if there's such an
> interpreter that works on Soot's IR, certain profiling would be quite easy
> to do in such an interpreter. If no such thing exists, can someone shed
> some light on how to profile the dynamical basic block counts of an
> entire program including libraries? Thanks a lot! Any comment is
> appreciated.
>
>
> Tong
> _______________________________________________
> 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: <https://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20181103/7c4260af/attachment.html>