Re: Instrument at marked locations

ThanhVu - If you are aiming for dynamic inter procedural analysis, you might want to consider using my Phosphor tool instead of starting from scratch (Phosphor is built on ASM). It gets very tricky and annoying to keep trace metadata associated with variables between methods - Phosphor handles this, and also infers data and control relations between variables.

In this example, you could (verbatim) put
x = MultiTainter.taintedInt(x,”some label for x”);
y = MultiTainter.taintedInt(y,”some label for y”);
and then could determine if z came from x or y with MultiTainter.getTaint(z); (which would be null if it wasn’t derived from something tainted, or would contain “some label for x” and/or “some label for y” depending on where it came from) 

Unfortunately the documentation is pretty scattered, but hopefully the integration tests give you some idea of what kinds of propagation it does - if you think it would be helpful but have questions feel free to let me know. https://github.com/gmu-swe/phosphor <https://github.com/gmu-swe/phosphor>

> On Dec 1, 2017, at 11:39 AM, ThanhVu (Vu) Nguyen <[email protected]> wrote:
> 
> Hi Eliot,  
> 
> Thanks! .  I'll try what you suggest.  
> 
> Back to your prev question about what my goal is.  I am developing a tool that detects properties at selected program location.  So the user can put something in the source code (e.g., //%trace x y z), and compile it with debugging enable (e.g., javac -g),  then give resulting class file to the tool.  The tool will process the class file, do instrumentation, etc ... and infer relationships among the x y z variables.
> 
> My goal is to reduce the user's work as much as possible, e.g., they just have to put in a comment like //%trace x y z.  But clearly comments are not carried over to bytecote so I try to find a different way. 
> 
> 
> 
> On Fri, Dec 1, 2017 at 10:30 AM Eliot Moss <[email protected] <mailto:[email protected]>> wrote:
> I wanted to post one more time to give more details of
> how you can actually do this.
> 
> Suppose the protocol is:
> 
>    Tracer.startTrace();
>    ... trace calls, e.g., Tracer.trace(var), Tracer.trace(expr), ...
>    Tracer.endTrace();
> 
> First, you have to wrap your ahead around the fact that you
> are using ASM as a tool to *remove* code, not one to *inject*
> code.  So you would have your tracing code in the source,
> but have it presented in a way that makes it possible (even
> easy) for ASM to cut it out.
> 
> The purpose of the startTrace call is to make it easy to find
> the bytecodes related to tracing, which necessarily start *before*
> the Tracer.trace calls, in order to push arguments.
> 
> So, the code exciser would look for calls of Trace.start/endTrace.
> Your method processor would include a boolean flag; let's call
> it "keeping".  When it sees startTrace, it would set keeping to
> false.  All the bytecode handling methods would do:
> 
>    if (keeping) {
>      pass this bytecode through
>    } /* otherwise nothing */
> 
> When endTrace is seen, you turn keeping back on (but after
> considering the call for processing).
> 
> This is pretty straight forward, but requires that you override
> a whole bunch of methods (but in a simple way).
> 
> A REFINEMENT:
> 
> If you want your tool to operate in a moe general and selective
> way, you could add a version of startTrace that takes a string:
> 
>    Tracer.startTrace("level 2 logging");
> 
> I assume the string is a constant.  By adding a bit of slightly
> tedious code, you can track whether the last thing pushed was a
> string constant, and if so, what its value is.  When you get to
> the call of startTrace(Ljava/lang/String;) you check that and
> use it to determine whether to turn keeping off or not.  You
> should complain it is if not a constant.
> 
> If you want NOT to keep the succeeding code, you replace the
> startTrace call with a POP (sorry, you have a PUSH/POP pair
> left -- but when code goes through a JIT compiler, this will
> disappear, so the ultimate overhead is not a big issue IMO).
> 
> Hope this helps!  Regards - Eliot Moss
> 
> -- 
> You receive this message as a subscriber of the [email protected] mailing list.
> To unsubscribe: mailto:[email protected]
> For general help: mailto:[email protected]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws


-- 
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws