Re: [Sablevm-developer] using a Soot-transformed classpath

[Chris P. <chr...@ma...>]

Clark VERBRUGGE wrote:
>>is this a soot bug?  generating code for java.lang.Object that declares 
>>java.lang.Object as a superclass?  or is there something particular to 
>>what i'm doing that forces java.lang.Object as a superclass (i don't see 
>>it ...)
>>
>>i checked the jasmin disassembly of the transformed java.lang.Object 
>>classfile and it does indeed declare '.super java/lang/Object'
> 
> 
> The super_class field of the classfile for java.lang.Object should be 0
> (ie invalid constant-pool ref), so that sounds like a soot bug.


Eric Bodden on the Soot list said it might be because two copies of 
java.lang.Object are in my classpath.  I tried the most minimal 
classpath I could find, and still had this problem.

What's weird is that with D-Java from

http://www.netsw.org/softeng/lang/java/bytecode/disassembler/djava/

I get:

$ cd ~/lib/sablevm/classpath
$ D-Java java/lang/Object.class -o jasmin

;>> java/lang/Object.class <<
;
; Output created by D-Java (Mar  8 2004)
; mailto:ums...@cc...
; Copyright (c) 1996-1997 Shawn Silverman
;

;Classfile version:
;    Major: 45
;    Minor: 3

.source Object.java
.class  public java/lang/Object
; ACC_SUPER bit is set
.super  java/lang/Object
^^^^^^^^^^^^^^^^^^^^^^^^

[...]

on a newly-installed classpath, which really doesn't make sense to me. 
Furthermore, when I step through this with gdb and sablevm, it doesn't 
think java.lang.Object has a superclass.  I installed D-Java to get 
straight jasmin output and try to pin down this problem -- Soot does 
some rearranging of instructions before spitting out Jasmin.

Can somebody else with sablevm-classpath installed verify this?  It 
takes less than 5 minutes.  I'm going a bit crazy with all these 
classpath issues.

Cheers, and thanks,
Chris