Wrestling with exceptions on win32 gcj 4.1

["tHE DPR" <dpr at aha dot lt>]

hello,

i'm trying to build a win32 crosscompiler on linux.
as i learned on this list already, exception support doesn't work very well 
on windows.
but i tried...

so, i was able to build a crosscompiler with these configure options:

Target: i686-pc-mingw32
Configured with: 
/home/dpr/gcc/gcc-4.1/configure --prefix=/home/dpr/gcc/crossgcc --target=i686-pc-mingw32 
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --enable-languages=c,c++,java 
--disable-nls --enable-threads=win32 --with-gcc --with-gnu-as --with-gnu-ld 
--without-newlib --disable-win32-registry --disable-shared --enable-libgcj  
--disable-java-awt --without-x --enable-java-gc=boehm --enable-interpreter --disable-debug 
--disable-libgcj-debug
Thread model: win32
gcc version 4.1.0 20060203 (prerelease)

compiler builds, a hello world builds, but doesn't work

as i figured out, the problem is that all libjava is built 
with -fomit-frame-pointer.
i hacked configure.host file and changed -fomit-frame-pointer 
to -fno-omit-frame-pointer.
now hellow world buils and runs ok.

now second problem...
it appears that it's impossible to load a jni library:

my modified hellow world crashes because of segfault:

public class Test
{
   public static void main(String[] args)
   {
       System.out.println("Hello, GCJ!");
       try
       {
           new StringBuffer().append("123".toCharArray(), 1, 5);
       }
       catch (Exception ex)
       {
           ex.printStackTrace();
       }
       System.loadLibrary("any-lib");
   }
}

(gdb) run
Starting program: N:\gcc\test/Test.exe
Hello, GCJ!
java.lang.StringIndexOutOfBoundsException
  at 0x548c48 (Unknown Source)
  at 0x40580e (Unknown Source)
  at 0x40a282 (Unknown Source)
  at 0x40a5d3 (Unknown Source)
  at 0x40a5ed (Unknown Source)
  at 0x40a60d (Unknown Source)
  at 0x40a6ad (Unknown Source)
  at 0x40a6cd (Unknown Source)
  at 0x4153aa (Unknown Source)
  at 0x401471 (Unknown Source)
  at 0x5af5cc (Unknown Source)
  at 0x430497 (Unknown Source)
  at 0x450b10 (Unknown Source)
  at 0x4042f0 (Unknown Source)
  at 0x404452 (Unknown Source)
  at 0x404487 (Unknown Source)
  at 0x401308 (Unknown Source)
  at 0x401233 (Unknown Source)
  at 0x401284 (Unknown Source)
  at 0x7c816d4b (Unknown Source)

Program received signal SIGSEGV, Segmentation fault.
0x00401679 in _Unwind_GetIP ()

(gdb) backtrace
#0  0x00401679 in _Unwind_GetIP ()
#1  0x0040196d in _Unwind_Backtrace ()
#2  0x0054f463 in _Jv_StackTrace::GetFirstNonSystemClassLoader ()
#3  0x0042bb91 in java::lang::Runtime::_load ()
#4  0x0040bb70 in java::lang::Runtime::loadLibrary ()
#5  0x0040b37c in java::lang::System::loadLibrary ()
#6  0x00401489 in dpr.Test.main(java.lang.String[]) (args=0xf76fb8)
   at dpr/Test.java:16
#7  0x005af5d0 in gnu::java::lang::MainThread::call_main ()
#8  0x0043049b in gnu::java::lang::MainThread::run ()
#9  0x00450b14 in _Jv_ThreadRun ()
#10 0x004042f4 in _Jv_RunMain ()
#11 0x00404456 in _Jv_RunMain ()
#12 0x0040448b in JvRunMain ()
#13 0x0040130c in main (argc=4199180, argv=0x731040) at /tmp/cc7J0XGe.i:11

(gdb) disassemble
Dump of assembler code for function _Unwind_GetIP:
0x00401670 <_Unwind_GetIP+0>:   push   %ebp
0x00401671 <_Unwind_GetIP+1>:   mov    %esp,%ebp
0x00401673 <_Unwind_GetIP+3>:   mov    0x8(%ebp),%eax
0x00401676 <_Unwind_GetIP+6>:   pop    %ebp
0x00401677 <_Unwind_GetIP+7>:   mov    (%eax),%eax
0x00401679 <_Unwind_GetIP+9>:   mov    0x4(%eax),%eax
0x0040167c <_Unwind_GetIP+12>:  inc    %eax
0x0040167d <_Unwind_GetIP+13>:  ret
0x0040167e <_Unwind_GetIP+14>:  mov    %esi,%esi
End of assembler dump.

i traced the problem down to the method
_Jv_StackTrace::UnwindTraceFn (btw, why it is not shown in backtrace?)

it appears that this callback method is handed a context where context->fc 
== 0,
and this happens after the last frame is processed with this data
 context->fc->prev      ==  0
 context->fc->call_site == -1

i hope this makes sense to you.

as i understand this, either UnwindTraceFn (or _Unwind_GetIP) should be 
prepared for this,
or _Unwind_Backtrace should not call a callback with such context.

btw, as i debugged all this, i noticed that UnwindTraceFn may return 
_URC_NORMAL_STOP (throught non_system_trace_fn), which is interpretted as 
_URC_FATAL_PHASE1_ERROR in _Unwind_Backtrace.

in the end i hope this is a simple to fix problem, or just my mistake..

bye,
dpr