crash loading gcj stuff
Godmar Back
gback at cs.utah.edu
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:
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.
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
information
- 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