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

[Andrew Haley]

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.