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. Thanks, Anthony Bryant.
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
On 11 February 2013 06:45, Bill Wendling <wendling at apple.com> wrote:> 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. >The ARM EHABI (zero-cost) implementation is in progress, but not complete. Some basic cases are reported to work, but also some simple cases are reported to fail. http://llvm.org/bugs/show_bug.cgi?id=7187 Anton and Logan are working on it, but replying to the bug is best. cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130211/d1710044/attachment.html>
Hi Bill, Thanks for the response, I just have a couple more questions. On 11 February 2013 06:45, Bill Wendling <wendling at apple.com> wrote:> 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. :)So it sounds like it's completely OS independent, but I just want to confirm - do the COFF and Mach-O outputs use the same system? Do I need to do anything special in order to get them to work? For example, do they generate different exception handling tables (using something other than the DWARF format), meaning that I'd have to write separate personality functions?> 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.Do I need to do anything different to generate SJLJ exception-handling bitcode? There are some intrinsics documented at http://llvm.org/docs/ExceptionHandling.html#llvm-eh-sjlj-setjmp - but there doesn't seem to be any documentation about how to use them. Are calls to them generated by an LLVM pass, or do I need to call them myself? My problem is that I want my bitcode to be platform independent, so if SJLJ requires me to generate special calls to intrinsics then I can't use LLVM's exception handling at all until LLVM supports one way of doing it on all platforms. Thanks, Anthony.