search for: __cxa_get_exception_ptr

...more closely in the > LLVM IR? (You could just specify that the llvm.eh.exception call has > to be at the start of a landing pad, but I think that is too prone to > being broken by optimisation passes.) > Well, it's not entirely magical. :-) It gets the exception object by calling __cxa_get_exception_ptr and __cxa_begin_catch (though both calls can be combined into __cxa_begin_catch, which is what we do). It's feasible to simply generate the llvm.eh.exception at the start of the catch block code and have that convert into the call to __cxa_begin_catch. My only concern is that we need to...

>> As I understand it, when you generate native code, at each landing pad >> the exception pointer appears magically in a well-known native >> register. > Well, it's not entirely magical. :-) It gets the exception object by calling > __cxa_get_exception_ptr __cxa_get_exception_ptr returns an "adjusted" pointer to the exception object, but you still have to pass into it a "raw" (unadjusted) pointer to the exception object. It's this raw pointer that appears magically in a native register at the start of a landing pad. > Wel...

> Please read and let me know your opinions! This definitely seems like an improvement on the current situation. >            .---------. >            | convoke | >            `---------' >                 | >                 v >     .-----------------------. >     |                       | >     v                       | >  %normal  

I've been looking into a new way to implement exception handling in LLVM. The current model has many disadvantages, in my opinion. I try to address them with this proposal. I also try to make exception handling much more understandable to the normal human reader. :-) Any new proposal will need to address all present and future languages' exception handling methodologies. I