<div dir="ltr">Thanks you, Elena. I think, that I can use different disassemblers for checking, e.g. Eclipse Bytecode Viewer. <div>I make obfuscations, <span style="color:rgb(0,0,0);font-size:13px;white-space:nowrap">therefore </span>I can add instructions after return sometimes.<br><div><br><div class="gmail_extra"><br><div class="gmail_quote">2015-02-06 21:51 GMT+03:00 Elena Sherman <span dir="ltr"><<a href="mailto:elenasherman@boisestate.edu" target="_blank">elenasherman@boisestate.edu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Eric, yes, it works correctly. I've added the print statement in Roman's code and it does prints out 500. So, I don't know if it should be reported or not. <div>When I was looking for the format of iinc_w I found the following</div><div>iinc_w index byte1 byte2</div><div>where the value to be incremented is calculated as byte1 << 8 | byte2</div><div>When I've changed the value to increment from 500 to 512 and javap changed the bytecode from "<span style="color:rgb(80,0,80);font-size:12.8000001907349px">iinc_w #0, 1" </span>to "<font color="#500050"><span style="font-size:12.8000001907349px">iinc_w #0, 2", so apparently javap shows only byte1 part since 1<<8 = 256 and 2<<8 is 512 but fails to show byte 2, which should be 244 for 500 and 0 for 512.</span></font></div><div><div><br><div>Roman, when you instrument the code make sure to add your instrumentation before return statement, for example by using units.insertBefore(....) or units.insertAfter(...) methods.</div></div><div><br></div></div></div><div class=""><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 6, 2015 at 5:37 AM, Eric Bodden <span dir="ltr"><<a href="mailto:eric.bodden@sit.fraunhofer.de" target="_blank">eric.bodden@sit.fraunhofer.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>Thanks a lot for the input Elena!<br>
<br>
</span>Wow, that's odd! I have never seen javap give such apparently false/misleading information. Is this something we should report to Oracle?<br>
<span><br>
Anyway, I would assume that the bytecode is actually correct?<br>
<br>
Cheers,<br>
Eric<br>
<br>
<br>
</span><div><div>> On 06.02.2015, at 01:22, Elena Sherman <<a href="mailto:elenasherman@boisestate.edu" target="_blank">elenasherman@boisestate.edu</a>> wrote:<br>
><br>
> Roman,<br>
><br>
> I've run your code with the initialization of the local variable part added to it. It looks like that depending on the bytecode viewer I get different bytecode. When I use javap -c Decomp.class I get the following (what you get):<br>
><br>
> Compiled from "Decomp.java"<br>
> public class decomp.Decomp {<br>
> public decomp.Decomp();<br>
> Code:<br>
> 0: aload_0<br>
> 1: invokespecial #1 // Method java/lang/Object."<init>":()V<br>
> 4: return<br>
> 5: iconst_0<br>
> 6: istore_0<br>
> 7: iinc_w #0, 1 // #0<br>
><br>
> public static void main(java.lang.String[]);<br>
> Code:<br>
> 0: return<br>
> 1: iconst_0<br>
> 2: istore_0<br>
> 3: iinc_w #0, 1 // #0<br>
> }<br>
><br>
> However, when I use Eclipse's bytecode viewer I get the following:<br>
><br>
> // Compiled from Decomp.java (version 1.2 : 46.0, super bit)<br>
> public class decomp.Decomp {<br>
> // Method descriptor #12 ()V<br>
> // Stack: 1, Locals: 1<br>
> public Decomp();<br>
> 0 aload_0 [this]<br>
> 1 invokespecial java.lang.Object() [1]<br>
> 4 return<br>
> 5 wide<br>
> 6 iinc 0 500 [this]<br>
> Line numbers:<br>
> [pc: 0, line: 0]<br>
> [pc: 1, line: 1]<br>
> [pc: 4, line: 2]<br>
> [pc: 5, line: 3]<br>
> Attribute: LineNumberTable Length: 18<br>
> Attribute: LineNumberTable Length: 18<br>
><br>
> // Method descriptor #11 ([Ljava/lang/String;)V<br>
> // Stack: 0, Locals: 1<br>
> public static void main(java.lang.String[] arg0);<br>
> 0 return<br>
> 1 wide<br>
> 2 iinc 0 500 [arg0]<br>
> Line numbers:<br>
> [pc: 0, line: 0]<br>
> [pc: 1, line: 1]<br>
> Attribute: LineNumberTable Length: 10<br>
> Attribute: LineNumberTable Length: 10<br>
> }<br>
><br>
> Which is correct. So, apparently the wide incremental instruction, i.e., iinc_w should be interpreted a bit different than its regular version iinc. I'm not a bytecode specialist, so I cannot tell exactly how to interpret iinc_w's arguments in terms of iinc.<br>
><br>
> In general bytecode can be quite confusing, so in order to check whether your instrumentation works as expected try to print something out like the value of the local variable you're trying to increment. Thus when you execute the instrumented code you will know for sure if this is what you want or not, or there are any errors in the instrumentation.<br>
><br>
> Hope it helps.<br>
><br>
> Elena<br>
><br>
> On Thu, Feb 5, 2015 at 11:38 AM, Roman Petriev <<a href="mailto:vvpiroman@gmail.com" target="_blank">vvpiroman@gmail.com</a>> wrote:<br>
> Test cases here.<br>
> Is it good? Do you need anything else?<br>
><br>
> 2015-02-05 12:58 GMT+03:00 Bodden, Eric <<a href="mailto:eric.bodden@sit.fraunhofer.de" target="_blank">eric.bodden@sit.fraunhofer.de</a>>:<br>
> Hi Roman.<br>
><br>
> > I hope that is (exactly) what you want to see.<br>
><br>
> Ideal would be a minimal but runnable example, including your driver class for Soot and the command-line options you are using. We should be able to reproduce this with as little effort as possible.<br>
><br>
> Thanks,<br>
> Eric<br>
><br>
><br>
<br>
</div></div><div><div>--<br>
Prof. Eric Bodden, Ph.D., <a href="http://sse.ec-spride.de/" target="_blank">http://sse.ec-spride.de/</a> <a href="http://bodden.de/" target="_blank">http://bodden.de/</a><br>
Head of Secure Software Engineering at Fraunhofer SIT, TU Darmstadt and EC SPRIDE<br>
Tel: <a href="tel:%2B49%206151%2016-75422" value="+4961511675422" target="_blank">+49 6151 16-75422</a> Fax: <a href="tel:%2B49%206151%20869-127" value="+496151869127" target="_blank">+49 6151 869-127</a><br>
Room B5.11, Fraunhofer SIT, Rheinstraße 75, 64295 Darmstadt<br>
<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div></div>