Java vs. Dwarf2 EH Unwinder

Bryce McKinlay bryce@waitaki.otago.ac.nz
Wed Mar 27 17:26:00 GMT 2002


Background:

Java has a rather serious EH problem on many platforms, specifically 
that it needs to be able to throw exceptions from a signal handler in 
order to implement NullPointerException, and possibly 
ArithmeticException, in hardware. The Dwarf2 unwinder cannot do this by 
itself because the signal handling frame set up by the OS does not have 
unwind info associated with it. The current workaround is the target 
macro MD_FALLBACK_FRAME_STATE_FOR which recognises signal handler frames 
and helps the unwinder out.

However:

- The macro is rather hairy and so far has only been implemented for a 
small subset of platforms using the dwarf2 unwinder, specifically linux 
on alpha, ppc, x86, and ia64.

- It can only unwind signal frames, which means we must call the kernel 
directly to ensure that there  are no other frames (eg from libc) in 
between, which are compiled without eh info. This is ok on linux but may 
not be possible on other OS's.

The only alternatives currently are to use SJLJ exceptions, which is 
undesirable due to their inefficiency and because the C++ compiler 
configured for SJLJ will generate code that is incompatible with other 
compilers; or to use -fcheck-references which is inefficient and does 
not work for C++ code (the CNI runtime code in libjava relies on the 
sigsegv->NullPointerException behaviour).

So...

Would it be possible to add another interface to the unwinder, a variant 
of _Unwind_RaiseException(), which takes an instruction pointer and 
frame pointer as a context to begin unwinding from? There would still be 
a small amount of platform specific code needed to take this info from 
the sigcontext and pass it to the unwinder, but this can be done in 
libjava and would be far easier to write than an 
MD_FALLBACK_FRAME_STATE_FOR, and the normal POSIX signal API could be 
used without having to worry about additional stack frames between the 
RaiseException() call and the frame of the function which generated the 
signal.

Is there any reason why this couldn't work?

regards

Bryce.




More information about the Java mailing list