crash loading gcj stuff

Godmar Back gback at
Wed Feb 2 16:57:30 PST 2000

Another thing about the exception stuff.

Since I needed a hook into libgcc2.a's exception mechanism, I duplicated
a piece of libgcc2.c in eh.c.  (Once/If Kaffe support works, this may be
included in the official libgcc2.c distribution since it's a hook that
could benefit other dcgs as well.)

The following cmd tells you what has changed between the libgcc2.c you've
checked and the one from which kaffe's eh.c was derived:

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:

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.

Let me add a general comment about how all this works.
Basically, we dispatch *all* exceptions through gcc's (slightly modified) 
runtime mechanism.  We can deliver them to both gcj-compiled as well as 
jitted handlers, which is great.

To make that work, we 
    - compile everything with -fexceptions.  This prevents the __throw
      mechanism from bailing out if it sees a frame w/o exception handling
    - hook into the unwinder right where it takes a pc and constructs the
      unwinding information.  If we're about to unwind a JIT frame, we
      carefully construct this information just like frame.c would from
      dwarf.    If this frame has a handler, we call it right away.
    - let gcj frames be handled normally.

- Godmar

More information about the kaffe mailing list