exceptions: gross hideous hack works, need guru to tell me if I have caused major breakage

Sat Dec 15 02:43:00 GMT 2001

Adam Megacz writes:
 > 
 > Anyways, there's an exception-handling example where they do little
 > more than register an exception handler, check the type of the
 > exception, and then throw a language exception (not an OS exception)
 > right out of the OS-exception handler.
 > 
 > I tried this, and it works. Incredibly simple, but it works.
 > 
 > I also found code on the mailing list from a while back that had some
 > rather complex technique for unrolling the stack to the appropriate
 > java exception handler, then figuring out the appropriate EBP/EIP/ESP
 > values for that handler and returning them from the signal handler,
 > along with instructions to the OS saying "take these register values
 > and resume from there". Unfortunately it used an interface to GCC's
 > exception logic that no longer works.
This logic has been moved from Java's own signal handler to
MD_FALLBACK_FRAME_STATE_FOR in the various gcc back ends. There are
versions for x86, ppc, Alpha and recently IA-64.
 > So I'm wondering which of these is true:
 > 
 > 1) I've done something horribly wrong, and it will come back to bite
 > me when I start incurring NullPointerExceptions in larger programs
If you have setjmp/longjmp exceptions you'll be fine: there is no need
to do anything special for NullPointerExceptions.
However, the DWARF exception unwinder needs a complete stack chain
that it can unwind. The code in MD_FALLBACK_FRAME_STATE_FOR
recognizes a signal handler frame and unwinds it so that the DWARF
exception unwinder can continue.
 > 2) The author of the old SEGV-to-NullPointerException code
me
 > did something way more complex than was required. 
Not exactly: it was necessary at the time, but is no longer necessary.
 > Perhaps this is because you can't just throw a language-level
 > exception out of a POSIX exception handler,
The C++ standard says this. The only strictly legal way to jump out
of such a signal handler is with a longjmp. So, if you're using
setjmp/longjmp exceptions you'll be fine.
 > but you _can_ do this on Win32?
 > 3) What I've done works, but yields invalid stack traces (which don't
 > work on Win32 anyways due to SJLJ, so it's all moot).
Well, that's a shame, but only to be expected.
 > Anyways, I know very, very little about signal handlers, either on
 > POSIX or Win32, but my gross hack works, and I'd appreciate input
 > from somebody who knows more than me on whether I need to take a
 > closer look at this.
You'll still need the magic in i386.h HANDLE_DIVIDE_OVERFLOW even if
you're using setjmp/longjmp exceptions. There's a comment at the top
of this code which explains why. Try running the test case
libjava.lang/Divide_1.java to see if your handler works.
If making this work is too much hassle, you could define
DIVIDESPEC=-fuse-divide-subroutine in libjava/configure.host. This
would in any case be a perfectly reasonable stopgap.
Andrew.