crash loading gcj stuff

[Godmar Back]

> 
> sh your_kaffe_tree/developers/geteh_from_libgcc2 your_gcc_cvs_tree/libgcc2.c | diff - your_kaffe_tree/kaffe/kaffevm/gcj/eh.c
> 
> So, I just did that and noticed that they fixed a lot of warnings
> (imagine that libgcc2.c didn't even compile with -Wall two months ago),
> but there seems to be a more significant change:
> FIRST_PSEUDO_REGISTER was replaced with DWARF_FRAME_REGISTER.
> 
> Unfortunately, I cannot use exported header files to keep those in sync,
> Could you grep your trees to check that we use the right value here?
> If those are out of sync, and FPR > DFR, that would explain your prob,
> I think.  We need to know what DWARF_FRAME_REGISTER is for x86.
> 

It's 17.  So change 19 -> 17 in i386/jit.h and try that.
Martin von Loewis (of Menar) changed that on Dec 29 in the gcc tree.

Let me make a comment here.  All this seems like a horrible fragile 
mess.  This, however, is only partially true:  yes, we do 
depend on some gcc/gdb internals.  Part of which can change.  However,
there's the part that depends on the architecture and the dwarf2 spec 
for the architecture (incidentally, Martin's change fixed gcc to 
restore binary compability for the x86!) These do not change very fast.

In addition, if/when gcj support works, we're striving to be able to
use a stable gcc release (such as 3.0), not cvs snapshots.

Here's another hint: if you use optimization as in -O2 or -O3, make sure
you also use -fkeep-inline to avoid that gcj removes the meta-information
for private methods it inlines.  I should mention that in the FAQ.

	- Godmar