[LLVMdev] Platform-independent Exception Handling

Bill Wendling wendling at apple.com
Sun Feb 10 22:45:10 PST 2013


On Feb 9, 2013, at 4:14 PM, Anthony Bryant <antjbryant at gmail.com> wrote:

> Greetings,
> 
> I'm trying to implement exception handling in my front end. I have a
> prototype working using the Itanium ABI on Linux x86_64, but I'm not
> sure how to proceed for other platforms.
> 
> So I was wondering: which OS/architecture combinations support
> zero-cost EH, and which support SJLJ?
> 
> My main concern is keeping the IR for call sites platform independent.
> Right now, it looks like to do that I might have to write my own
> exception handling system (i.e. without invoke/landingpad) using just
> setjmp(), longjmp(), and some thread local variables - which I have a
> working prototype for, but it's quite inefficient. If LLVM's zero-cost
> handling is viable for all platforms, I'd much rather use that.
> 
> Any help would be appreciated.
> 
Hi Anthony,

As far as which OS/architectures support zero-cost EH and which support SJLJ, LLVM is designed to assume that Intel supports zero-cost exceptions and ARM supports SjLj exceptions. However, it's all in the personality function and unwind library. So it's not required that ARM use only SJLJ, it's just how it works because of the personality function and unwind library. :)

The invoke/landingpad/resume instructions are meant to be platform independent. However, there is a "lowering" phase that occurs before code generation that converts those instructions into the form needed for the EH support on the architecture we're compiling for. And during code generation, we generate different EH tables based on that decision. So basically it's converted into platform-specific code right before code generation happens.

That's a long-winded way of saying that you should use our current EH model and assume zero-cost exceptions unless you're on ARM (there is an ARM EABI which isn't SJLJ-based (from my understanding), but I don't know the status of that in LLVM) or have been proven otherwise.

-bw




More information about the llvm-dev mailing list