Re: Eclipse vs gij/libgcj, unit-at-a-time, -O2 and -O

[Jeff Sturm <jsturm at one-point dot com>]

On Mon, 3 Nov 2003, Mark Wielaard wrote:
> - The hard part was figuring out why it doesn't work with a default
> libgcj compile. I don't have a reduced test case yet but it seems that
> when libgcj is compiled with -O2 (which is standard) all kind of things
> get miscompiled.

I took a look at this today.  I'm trying Eclipse 2.1 with gij from
mainline, built with -O2.

Exception traces aren't very helpful:

!ENTRY org.eclipse.core.launcher 4 0 Nov 29, 2003 14:42:56.904
!MESSAGE Exception launching the Eclipse Platform:
!STACK
java.lang.NoClassDefFoundError:
org.eclipse.core.internal.boot.InternalBootLoader not found in
[file:/opt/eclipse/startup.jar, core:/]
   at _Jv_CallAnyMethodA(java.lang.Object, java.lang.Class, _Jv_Method,
boolean, boolean, java.lang.Class[], jvalue, jvalue, boolean)
(/opt/gcc/lib/libgcj.so.4.0.0)

gdb reveals more clues:

(gdb) bt
#0
java.lang.ClassNotFoundException.ClassNotFoundException(java.lang.String)
(
    this=@8185498, s=@8185498)
    at ../../../libjava/java/lang/ClassNotFoundException.java:83
#1  0x40527d9b in java.net.URLClassLoader.findClass(java.lang.String) (
    this=@80b6f88, className=@809a780)
    at ../../../libjava/java/net/URLClassLoader.java:853
#2  0x40422f52 in
gnu::gcj::runtime::VMClassLoader::findClass(java::lang::String*)
(this=@80b6f88, name=@809a780)
    at ../../../libjava/gnu/gcj/runtime/natVMClassLoader.cc:74
#3  0x4043f2b3 in java.lang.ClassLoader.loadClass(java.lang.String,
boolean) (
    this=@80b6f88, name=@809a780, resolve=false)
    at ../../../libjava/java/lang/ClassLoader.java:309
#4  0x4042c932 in _Jv_FindClass(_Jv_Utf8Const*, java::lang::ClassLoader*)
(
    name=@81df620, loader=null)
    at ../../../libjava/java/lang/natClassLoader.cc:506
#5  0x4042c181 in java::lang::Class::forName(java::lang::String*, bool,
java::lang::ClassLoader*) (className=@809a7f8, initialize=1, loader=null)
    at ../../../libjava/java/lang/natClass.cc:81
#6  0x4042c2de in java::lang::Class::forName(java::lang::String*) (
    className=@8185498) at ../../../libjava/java/lang/natClass.cc:113
#7  0x405fdf4b in ffi_call_SYSV () at ../../../libffi/src/x86/sysv.S:60

So the eclipse code calls the single-argument Class.forName(), which walks
the stack frame to find a loader and fails, presumably because
_Jv_StartOfInterpreter and _Jv_EndOfInterpreter no longer surround the
_Jv_InterpMethod::run method in generated code.

00000680 T _Z22_Jv_StartOfInterpreterv
00000690 T _Z20_Jv_EndOfInterpreterv
000006e0 T _ZN16_Jv_InterpMethod3runEPvP7ffi_raw

I guess we could force interpret.o to be built with -fno-unit-at-a-time
unless someone has a better idea.

 Jeff