
<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Feb 11, 2013, at 7:39 AM, Anthony Bryant <<a href="mailto:antjbryant@gmail.com">antjbryant@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi Bill,<br><br>Thanks for the response, I just have a couple more questions.<br><br>On 11 February 2013 06:45, Bill Wendling <<a href="mailto:wendling@apple.com">wendling@apple.com</a>> wrote:<br><blockquote type="cite">As far as which OS/architectures support zero-cost EH and which<br>support SJLJ, LLVM is designed to assume that Intel supports zero-cost<br>exceptions and ARM supports SjLj exceptions. However, it's all in the<br>personality function and unwind library. So it's not required that ARM<br>use only SJLJ, it's just how it works because of the personality<br>function and unwind library. :)<br></blockquote><br>So it sounds like it's completely OS independent,</blockquote><div><br></div><div>That was the intention, anyway. :)</div><br><blockquote type="cite"> but I just want to<br>confirm - do the COFF and Mach-O outputs use the same system? Do I need<br>to do anything special in order to get them to work?<br></blockquote><div><br></div><div>They should use the same system. The code to emit DWARF exceptions and debug information is in one place and doesn't have code in it that's target-dependent.</div><br><blockquote type="cite">For example, do they generate different exception handling tables (using<br>something other than the DWARF format), meaning that I'd have to write<br>separate personality functions?<br><br></blockquote><div>I'm not familiar with COFF, but no we would generate the same EH tables regardless of the file format.</div><br><blockquote type="cite"><blockquote type="cite">The invoke/landingpad/resume instructions are meant to be platform<br>independent. However, there is a "lowering" phase that occurs before<br>code generation that converts those instructions into the form needed<br>for the EH support on the architecture we're compiling for. And during<br>code generation, we generate different EH tables based on that<br>decision. So basically it's converted into platform-specific code<br>right before code generation happens.<br><br>That's a long-winded way of saying that you should use our current EH<br>model and assume zero-cost exceptions unless you're on ARM (there is<br>an ARM EABI which isn't SJLJ-based (from my understanding), but I<br>don't know the status of that in LLVM) or have been proven otherwise.<br></blockquote><br>Do I need to do anything different to generate SJLJ exception-handling<br>bitcode? There are some intrinsics documented at<br><a href="http://llvm.org/docs/ExceptionHandling.html#llvm-eh-sjlj-setjmp">http://llvm.org/docs/ExceptionHandling.html#llvm-eh-sjlj-setjmp</a> - but<br>there doesn't seem to be any documentation about how to use them. Are<br>calls to them generated by an LLVM pass, or do I need to call them<br>myself?<br><br></blockquote><div>Some of the intrinsics are generated by the front-end and the rest are generated during code-generation. The one that the front-end generates is the <tt class="docutils literal" style="color: rgb(36, 145, 207); text-decoration: none; font-family: Consolas, 'Deja Vu Sans Mono', 'Bitstream Vera Sans Mono', monospace; font-size: 0.95em; line-height: 21px; text-align: left; background-color: transparent; font-weight: bold; border: none; "><span class="pre"><a class="reference internal" href="http://llvm.org/docs/ExceptionHandling.html#llvm-eh-typeid-for" id="id16" style="color: rgb(36, 145, 207); text-decoration: none; font-family: 'Lucida Grande', 'Lucida Sans Unicode', Geneva, Verdana, sans-serif; font-size: 14px; line-height: 21px; text-align: left; background-color: rgb(248, 248, 248); ">llvm.eh.typeid.for</a> intrinsic.</span></tt></div><div>However, that intrinsic is used by both DWARF and SjLj exceptions.</div><br><blockquote type="cite">My problem is that I want my bitcode to be platform independent, so if<br>SJLJ requires me to generate special calls to intrinsics then I can't<br>use LLVM's exception handling at all until LLVM supports one way of<br>doing it on all platforms.<br><br></blockquote>That's a problem, because bitcode isn't platform independent. :-) But as far as the exception handling in LLVM, it should be platform independent until you get to the code-generation phase.</div><div><br></div><div>-bw</div><div><br></div></body></html>