This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Java vs. Dwarf2 EH Unwinder


Minor comments:

The IA64 unwinder at least needs more context than just the instruction and
frame pointer from the signal handler frame.  For example, the return
address at the exception point may have been stored in a different register.

On IA64, everything has unwind information, so you can unwind through libc
frames.

I copied David Mosberger, who may have further comments.

Hans

> -----Original Message-----
> From: Bryce McKinlay [mailto:bryce@waitaki.otago.ac.nz]
> Sent: Wednesday, March 27, 2002 5:25 PM
> To: java@gcc.gnu.org; gcc@gcc.gnu.org
> Subject: Java vs. Dwarf2 EH Unwinder
> 
> 
> 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.
> 
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]