[LLVMdev] RFC: New Exception Handling Proposal

Jay Foad jay.foad at gmail.com
Tue Nov 24 02:15:15 PST 2009


>> 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.

> Well, be warned that there can be multiple convokes which jump to the same
> landing pads. So there cannot be a one-to-one correspondence between them.
> However, an llvm.eh.exception should be dominated by at least one convoke.
> The only other problem I can see is if code branches into a catch block.
> It's gross, but could happen. In that case, the llvm.eh.exception should
> *not* be executed, because it's metadata constructed by the compiler, not
> user code. It would have to be peeled out into its own basic block in such
> instances.

Are you saying that, in the LLVM IR, it would be legal to have an
llvm.eh.exception that *isn't* dominated by convokes (because there's
a direct branch to that catch block), and in that case the call
returns an undefined value? And it would be up to codegen to "peel it
out into its own basic block"?

Thanks,
Jay.



More information about the llvm-dev mailing list