<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 7, 2007, at 4:40 PM, Dale Johannesen wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">So I couldn't get exceptions to work on PPC darwin. After much digging and confusion, there seem<div>to be two separate issues. </div></div></blockquote><div><br class="webkit-block-placeholder"></div>Ok.</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>The gcc testsuite is running the version of the unwinding code that was built with the local (llvm-)gcc, </div><div>which doesn't work because nobody has implemented builtin_return_address for that target. </div><div>So that's one problem.</div></div></blockquote><div><br class="webkit-block-placeholder"></div><div>That's an easy problem. I just implemented __builtin_return_address on PPC, at least builtin_return_address(0), please let me know if that is sufficient.</div><div><br></div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><div>More seriously, the version of the unwinding code installed on the system doesn't work either, for a</div><div>different reason (and also doesn't work on x86 Darwin). It turns out the installed code has the </div><div>following patch, which is not in the llvm-gcc source (or Apple's gcc sources for that matter; libgcc </div><div>lives in a separate repository these days):</div></div></div></div></blockquote><div><br class="webkit-block-placeholder"></div>Yuck :)</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><div><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">Index: gcc/unwind-dw2.c</span></div><div><div>===================================================================</div><div>--- gcc/unwind-dw2.c (revision 124749)</div><div>+++ gcc/unwind-dw2.c (working copy)</div><div>@@ -1526,7 +1526,7 @@</div><div> static inline _Unwind_Ptr</div><div> uw_identify_context (struct _Unwind_Context *context)</div><div> {</div><div>- return _Unwind_GetIP (context);</div><div>+ return _Unwind_GetCFA (context);</div><div> }</div><div><br></div><div>I'm uncertain of the merit of this patch, but it's in shipping Leopard and works with gcc, so we're</div><div>stuck with it. </div></div></div></div></div></blockquote><div><br class="webkit-block-placeholder"></div>Right, this is effectively part of the darwin ABI now.</div><div><br class="webkit-block-placeholder"></div><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><div><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">The effect of this is that llvm's strategy of making every C++ selector claim that it has a catch-all</span></div><div>handler at the end, as described here</div><div><a href="http://llvm.org/docs/ExceptionHandling.html">http://llvm.org/docs/ExceptionHandling.html</a>#restrictions</div><div>does not work in this environment. Claiming that a function has a catch-all handler when it does</div><div>not causes the unwinder to go into a loop.</div></div></div></div></blockquote><div><br class="webkit-block-placeholder"></div><div>Okay, you're beyond my knowledge here :)</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><div>I tried simply removing the code that does this:</div><div><br class="webkit-block-placeholder"></div><div><div>Index: cp/except.c</div><div>===================================================================</div><div>--- cp/except.c<span class="Apple-tab-span" style="white-space:pre"> </span>(revision 44663)</div><div>+++ cp/except.c<span class="Apple-tab-span" style="white-space:pre"> </span>(working copy)</div><div>@@ -104,7 +104,7 @@</div><div> lang_eh_runtime_type = build_eh_type_type;</div><div> lang_protect_cleanup_actions = &cp_protect_cleanup_actions;</div><div> /* LLVM local */</div><div>- lang_eh_catch_all = return_null_tree;</div><div>+/* lang_eh_catch_all = return_null_tree;*/</div><div> }</div><div> </div><div> /* Returns an expression to be executed if an unhandled exception is</div><div><br class="webkit-block-placeholder"></div><div>and that works well for me; i.e., the gcc tests that exercise exceptions work as well with the</div><div>two patches above (on x86) as they did before.</div></div></div></div></div></blockquote><div><br class="webkit-block-placeholder"></div><div>Ok, cool :) Duncan, Anton, what do you guys think about this?</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><div><div>Now I need some help:</div><div>- Why was C++ claiming that every selector has a catch-all handler? The documentation above just says </div><div><span class="Apple-style-span" style="font-family: Times; "></span></div><div><span class="Apple-style-span" style="font-family: Times; ">the C++ personality function will terminate the program if it detects that unwinding the exception only results in matches with cleanups.</span></div><div>Isn't that what's supposed to happen if there's no handler anywhere?</div><div>- What is the right thing for Linux? Is the deletion above safe there?</div></div></div></div></div></blockquote><br></div><div>Unsure,</div><div><br class="webkit-block-placeholder"></div><div>-Chris</div></body></html>