Re: Small note [Fwd: troubles with defineClass and Binary Compatibility on ARM-Linux]

[Andrew Haley <aph at redhat dot com>]

Philippe Laporte writes:
 > Hi,
 >    Thanks for your answer.
 > 
 > On Thu, 2006-06-22 at 12:39 -0600, Tom Tromey wrote:
 > > >>>>> "Philippe" == Philippe Laporte <philippe.laporte@gatespacetelematics.com> writes:
 > > 
 > > Philippe> for bundles:
 > > Philippe> [Loaded (bytecode) org.knopflerfish.bundle.log.LogConfigImpl from (null
 > > Philippe> <no certificates>)]
 > > Philippe> So all is happy on x86.
 > > 
 > > On x86 in this case you are loading bytecode...
 > 
 > As reported by "Loaded (bytecode)". I meant to acknowledge this when I
 > wrote, just before that excerpt:
 > 
 > "If instead I run 
 > ./kf -verbose:class -jar framework.jar -init
 > "
 > 
 > Since I am not supplying the DB argument, it can't find the native code,
 > so it has to interpret (load bytecode).
 > 
 > When I supply the DB argument, everything is loaded from native code. So
 > all is fine on x86.
 > 
 > > 
 > > Philippe> Now on ARM,
 > > 
 > > Philippe> Caused by: java.lang.NullPointerException
 > > Philippe>    at java.lang.ClassLoader.defineClass(java.lang.String, byte[], int,
 > > Philippe> int) (/usr/lib/libgcj.so.6)
 > > 
 > > You're hitting:
 > > 
 > >     http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27294
 > > 
 > > This is fixed on trunk -- there you would get a message about loading
 > > bytecode without the interpreter being available.
 > 
 > This was from a 4.0.2 run. 
 > 
 > I also reported the results from a 4.2-20060617 which were
 > 
 > [Loaded (BC-compiled) org.knopflerfish.framework.BundleImpl from <no
 > code source>]
 > [Loaded (pre-compiled) org.osgi.framework.Bundle from <no code source>]
 > [Loaded (BC-compiled) org.knopflerfish.framework.Debug from <no code
 > source>]
 > [Loaded (pre-compiled) java.lang.InterruptedException from <no code
 > source>]
 > [Loaded (pre-compiled) java.lang.NumberFormatException from <no code
 > source>]
 > [Loaded (pre-compiled) java.net.MalformedURLException from <no code
 > source>]
 > [Loaded (pre-compiled) java.lang.NoClassDefFoundError from <no code
 > source>]
 > [Loaded (pre-compiled) java.lang.LinkageError from <no code source>]
 > Exception in thread "main" [Loaded (pre-compiled) java.lang.Throwable
 > $StaticData from <no code source>]
 > java.lang.NullPointerException
 >    <<No stacktrace available>>
 > 
 > > The problem is as Andrew said -- no one has written the libffi
 > > closure API for ARM, so the interpreter is not available.  This
 > > means that if your class is not in the class cache, you'll get an
 > > exception.
 > 
 > The class cache is the repository pointed to by the app DB
 > generated with gcj-dbtool, or equivalently if one uses GCJ as as
 > JIT (with -Dgnu.gcj.jit.compiler=$GCJ
 > -Dgnu.gcj.jit.cachedir=$GCJ-CACHE), correct?.

Yes, that's what he means.

 > So from what I wrote previously what you are saying is that emy app
 > DB points to the wrong place? But I've got the feeling that it is
 > OK and that the Java code is pure native. I thought Andrew had
 > acknowledged that.

Tom doesn't know one way or the other because he doesn't have access
to your system.

 > Is there a verbose option to see where libgcj tries to load the native
 > codes from?

No, but you don't need it because you can use strace.  "strace
-etrace=file" will show you what files libgcj tries to open.

 > libffi is not needed to link against native code?

That's right.

 > As soon as we can clarify things I will jump into GDB. I'd just
 > like to make sure the situation is narrowed down first.

That's what gdb is for.  Narrowing things down.  We need to know the
actual cause of the segv.  We also need to know the reason for the
lack of stack traces.  If it's that the ARM gcc doesn't support DWARF
unwinding, we need to know that.

 > How much work are the remaining tasks for libffi to work on ARM, in
 > your estimate?

Writing the closure API is a small number of days for someone with
access to a system and knows what they are doing.

Andrew.