Finally Got GCJ 3.4 Working Under MingW

Fri May 16 08:29:00 GMT 2003

Ranjit,
>> >The rest of the code that you have replaced seems to be there *as is*
>> >in 3.3 as well, so why should it be causing problems in 3.4? Something
>> >else is hosed up badly in 3.4...
>>>> Even with 3.3, stack frames get corrupted if an exception is thrown during
>> bootstrapping. The new 3.4 java.io stuff brought this out. I don't know why
>> the corruption happens. Does this have anything to do with the SEH stuff
>> you were working on?
>>Can you please elaborate on this? This looks like a serious problem.

Sorry it's taken me so long to follow up on this. I don't have a whole lot of
time to spend on this, so hopefully I can communicate this well enough.
I wanted to produce a simple test case, but I don't think that's going to
happen soon.
Flashback to 3.3: The thing that caused me to uncover the fact that your original cross-configury
patch needed more tweaking was when I tried to compile and run an SWT
application (which uses JNI) using the linux -> mingw32 cross compiler. The
executable screamed that Runtime.loadLibrary() wasn't implemented. When
I then "turned on" libltdl support in configure.in, the executable complained
that it couldn't locate the shared library.
Huh? Couldn't locate the shared library? It's right there in front of you. What's
your problem?
Here was the problem:
- your original patch made the cross-compiler configury fall into the
 "we assume newlib" part of configure.in, therefore HAVE_BACKTRACE
 wasn't defined
- go to java/lang/natRuntime.cc. Locate this section of code:
------------------------------------------------------------8<----------------------------------------------------------
 char *lib_name = buf;
 if (do_search)
 {
 ClassLoader *sys = ClassLoader::getSystemClassLoader();
 ClassLoader *look = NULL;
 gnu::gcj::runtime::StackTrace *t = new gnu::gcj::runtime::StackTrace(10);
 try
 	{
	 for (int i = 0; i < 10; ++i)
	 {
	 jclass klass = t->classAt(i);
	 if (klass != NULL)
		{
		 ClassLoader *loader = klass->getClassLoaderInternal();
		 if (loader != NULL && loader != sys)
		 {
		 look = loader;
		 break;
		 }
		}
	 }
	}
 catch (::java::lang::ArrayIndexOutOfBoundsException *e)
	{
	}
------------------------------------------------------------8<----------------------------------------------------------
Note char* lib_name = buf at the top. Note also how the author is unnecessarily
relying on an ArrayIndexOutOfBoundsException to break out of the loop instead
of simply testing t->length().
With the mingw32 cross compiler, when HAVE_BACKTRACE is undefined, the
stack trace has a 0 length and you get the ArrayIndexOutOfBoundsException
immediately. And after that, lib_name points to garbage instead of the actual
library name, indicating some sort of stack (frame) weirdness. This weirdness
disappeared when I used t->length() and your original configury patch; even
though stack traces still didn't work, I was able to build and run the HelloSWT
application.
This weirdness rears its ugly head in 3.4 again because during bootstrapping,
the new java.io stuff called valid() in natFileDescriptor.cc with a console handle,
which threw a SecurityException and messed up the world.
I don't know:
- if this is also an issue with the crossed-native compiler (libstdc++ 3.4 configury
 issues prevented me from building the crossed-native compiler - I haven't
 followed up on this or done a fresh CVS get in a couple of weeks. I know
 I don't need libstdc++ for libgcj, but didn't feel like working around this.)
- if this is a problem after bootstrapping and if not, why not. I can't imagine
 that this is a problem after bootstrapping because people would have
 screamed long time ago.
So that's where things are at. I am short on free time these days, so I haven't
been able to research this as thoroughly as I'd like.
-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/