[Soot-list] Instrumentation problem for GOTO instructions

[Aaloan Miftah]

Hey Joe,

This is a problem with Jasmin, I have attached a patch that _should_ work (note: you will need to apply the patch & compile Jasmin from source).

Regards,

Aaloan


________________________________
 From: Joe <owqian at gmail.com>
To: soot-list <soot-list at sable.mcgill.ca> 
Sent: Saturday, March 24, 2012 8:41 AM
Subject: Re: [Soot-list] Instrumentation problem for GOTO instructions
 

Hi Eric,

   I mean instrumenting the instructions and hooking the execution
      of each assignment and method call.
The instrumented bytecode is like following: 

   1886:    aload    59
   1888:    invokestatic    #1818; //Method
com/xxx/tracer/RefTracer.afterInstanceFieldLoad:(JILjava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)V
   1891:    aload    22
   1893:    astore    184
   1895:    iload    27
   1897:    invokestatic    #1393; //Method
      soot/jimple/IntConstant.v:(I)Lsoot/jimple/IntConstant;
   1900:    astore    22
   1902:    lload    182
   1904:    ldc_w    #1586; //int 545952
   1907:    aload    184
   1909:    aload    22
   1911:    invokestatic    #431; //Method
com/xxx/tracer/RefTracer.afterAssignByStaticCall:(JILjava/lang/Object;Ljava/lang/Object;)V
   1914:    aload    60
   1916:    astore    184


   I use JustIce to verify the instrumented bytecode. The tool reports "bad bytecode", because
there are invalid branch targets in the instrumented code. I've
      checked the instrumented Jimple representation,
and its Jasmin format. The jump statements are correct. But when
      the jasmin format is translated to .class format. 
The goto instructions jump to incorrect locations.

   2034:    invokevirtual    #959; //Method
soot/jimple/Jimple.newAssignStmt:(Lsoot/Value;Lsoot/Value;)Lsoot/jimple/AssignStmt;
   2037:    astore    20
   2039:    lload    182
   2041:    ldc_w    #1587; //int 545950
   2044:    aload    184
   2046:    aload    20
   2048:    aload    60
   2050:    invokestatic    #604; //Method
com/xxx/tracer/RefTracer.afterAssignByInstanceCall:(JILjava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)V
   2053:    goto    -14285      // should be a positive number, turn to negative because of integer overflow
   ....

   51251:    aload    20        // jump target
   51253:    aconst_null
   51254:    invokestatic    #1049; //Method
com/xxx/tracer/RefTracer.beforeRefEqualityTest:(Ljava/lang/Object;Ljava/lang/Object;)V
   51257:    aload    20
   51259:    ifnull    51395
   51262:    aload    180


   The reason is that after instrumentation the goto offset largely increases compared to the original one 
(larger than a short integer type, because of the added code), but
      we still use goto instead of goto_w in the 
generated bytecode. 

   I think this kind of situation rarely occurs. Maybe we do not
      need to fix the bug. But, its better
to given a warning when use Jasmin to generate the bytecode.

   Thanks for your reply.

Regards,

Joe 
   



On 2012/3/24 18:14, Eric Bodden wrote: 
Hi Joe. Sorry but what exactly do you mean by "hooking"? Cheers,
Eric On 24 March 2012 09:52, Joe <owqian at gmail.com> wrote: 
>Hi All,        I find a strange problem when hooking soot.coffi.CFG.generateJimple
method.
The method is very large. After hooking, the goto instructions become
invalid. It seems
that the jump offsets overflow the short  integer type.
      (The hooked method is still less than 64k bytes. No more than the
maximum JVM method size. )         package jas;
        public class Label extends Insn implements RuntimeConstants
        {
              void writeOffset(CodeAttr ce, Insn source, DataOutputStream
out)
                           throws jasError, IOException
             {                             // write the offset (as a short)
                                // of source
                     int pc, tpc;
                    pc = ce.getPc(this);                   // pc = 51250
                    if (source == null)
                          tpc = 0;
                    else
                          tpc = ce.getPc(source);        // tpc = 2053
                    short offset = (short) (pc - tpc);   // overflow here
                    out.writeShort(offset);
          }          Now, I'm searching for ways to fix this problem. Can Soot
automatically change
 the goto instructions into goto_w instructions? Joe _______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20120324/6c4c42fb/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: goto.patch
Type: application/octet-stream
Size: 1442 bytes
Desc: not available
Url : http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20120324/6c4c42fb/attachment-0001.obj