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

[Zhou, Tong]

Hi Ben,


Thanks again for the guidance! As I understand it, you made a few points:


  1.  Overwriting the entire rt.jar might be easier than just overwriting a few classes (https://jreframeworker.com) has an example that does that.
JReFrameworker – Making Java Bytecode Manipulations Easier<https://jreframeworker.com/>
jreframeworker.com
JReFrameworker. This project aims to extend previous works by Erez Metula by introducing JReFrameworker, a tool to produce MCR capabilities aimed at the Java Runtime Environment in a user-friendly way.. JReFrameworker is a bytecode manipulation tool that allows a user to write annotated Java source that is automatically merged or inserted into the runtime.


  2.   Soot might have issue transforming Java 8 rt.jar but Java 7 should work.


Thank you very much for your information. Really appreciate it! I'll let you know if I successfully achieve that.


Tong

________________________________
From: Ben Holland <benjholla at gmail.com>
Sent: Saturday, November 3, 2018 5:33:07 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

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<mailto: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<mailto:benjholla at gmail.com>>
Sent: Saturday, November 3, 2018 4:52:26 PM
To: Zhou, Tong
Cc: soot-list at cs.mcgill.ca<mailto: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<mailto: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<mailto: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/d4d9454e/attachment-0001.html>