[Soot-list] CFG: RuntimeException: Attempting to push a non-constant cp entry

[John Jorgensen]

>>>>> "slusanschi" == Emil Slusanschi <slusanschi at sc.rwth-aachen.de> writes:

    slusanschi> Hi, I have a problem: when I try to use the -w
    slusanschi> (or -W for that matter) flag with a very small
    slusanschi> class like: [...]

    slusanschi> with the following command line:

    slusanschi> java soot.Main -w -f jimple --soot-classpath \
    slusanschi> .:/home/af016es/work/java/j2sdk1.5.0/jre/lib/rt.jar:gnu-crypto-2.0.1-bin/lib/javax-crypto.jar Test

    slusanschi> I get the following Runtime Exception: [...]

    slusanschi> java.lang.RuntimeException: Attempting to push a
    slusanschi> non-constant cp entry at
    slusanschi> soot.coffi.CFG.processCPEntry(CFG.java:2695) at

I still don't have a solution, but I know what triggers the
problem: the second instruction in the method
org.omg.CORBA.IDLTypeHelper.read() from jdk1.5.0's rt.jar:

 public static org.omg.CORBA.IDLType read(org.omg.CORBA.portable.InputStream);
   Signature: (Lorg/omg/CORBA/portable/InputStream;)Lorg/omg/CORBA/IDLType;
   Code:
    0:	aload_0
    1:	ldc_w	#50; //class org/omg/CORBA/_IDLTypeStub
    4:	invokevirtual	#106; //Method org/omg/CORBA/portable/InputStream.read_Object:(Ljava/lang/Class;)Lorg/omg/CORBA/Object;
    7:	invokestatic	#100; //Method narrow:(Lorg/omg/CORBA/Object;)Lorg/omg/CORBA/IDLType;
    10:	areturn

(org.omg.CORBA.IDLTypeHelper.narrow() would probably also fail if
the first exception didn't abort since it also includes a
reference to #50.)

Soot is still enforcing that ldc* can only load numbers and
strings, but jdk 1.5.0 uses a proposed change to the VM
specification allowing these instructions to load class constants
as well.  See:
http://java.sun.com/docs/books/vmspec/2nd-edition/jvms-proposed-changes.html

I haven't checked to see how difficult it will be to make
soot.coffi accommodate the changes to the class file format and
instruction set. I actually like this sort of thing, so I'll
volunteer to do the work, but it will likely be two or three
weeks before I can get to it. So if somebody needs to be able to
jimplify jdk 1.5.0's rt.jar before then, you'll need a different
volunteer.