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

[Philippe Laporte <philippe dot laporte at gatespacetelematics dot com>]

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?. 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. 

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

libffi is not needed to link against native code?

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.

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

Thanks a whole bunch,

-- 
Philippe Laporte