<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br><div><div>On Jul 27, 2011, at 11:10 AM, John McCall wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Monaco; min-height: 16.0px"><br></p> <blockquote type="cite"><p style="margin: 0.0px 0.0px 0.0px 10.0px"><font face="Monaco" size="3" style="font: 12.0px Monaco">4)<span class="Apple-converted-space"> </span>IIUC, llvm has inherited a bug from gcc where the debugger cannot let the user know an exception is</font></p> <p style="margin: 0.0px 0.0px 0.0px 10.0px"><font face="Monaco" size="3" style="font: 12.0px Monaco">going to be uncaught until after the stack has been unwound -- contrary to the design intentions of the<span class="Apple-converted-space"> </span></font></p> <p style="margin: 0.0px 0.0px 0.0px 10.0px"><font face="Monaco" size="3" style="font: 12.0px Monaco">unwind library that most exception implementations are based on (with a two phase unwind algorithm) --</font></p> <p style="margin: 0.0px 0.0px 0.0px 10.0px"><font face="Monaco" size="3" style="font: 12.0px Monaco">which creates a problem for the debugger user.</font></p> </blockquote><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Monaco; min-height: 16.0px"><br></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Monaco" size="3" style="font: 12.0px Monaco">I don't see this as a compiler bug.<span class="Apple-converted-space"> </span>I can't imagine any personality function</font></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Monaco" size="3" style="font: 12.0px Monaco">design which would let debuggers interrupt or control unwinding without</font></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Monaco" size="3" style="font: 12.0px Monaco">hooking libUnwind, short of requiring every single call to have an</font></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Monaco" size="3" style="font: 12.0px Monaco">associated landing pad which the personality always lands at, even if</font></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Monaco" size="3" style="font: 12.0px Monaco">there's nothing to do there.<span class="Apple-converted-space"> </span>That will never, ever be acceptable.</font></p> </blockquote></div><br><div><br></div><div>John,</div><div> I'm not able to figure out what you're really trying to say here. I am suggesting that</div><div>there be a unique function that libUnwind calls in the event it detects that an exception</div><div>is going to go uncaught all the way out past main, and that the user be able to set a</div><div>break-point on that function (it could be the existing function "terminate", or a new one</div><div>created just for this one purpose), so that the stack can be examined before it gets</div><div>unwound.</div><div><br></div><div>I'm not sure what you mean by "hooking", "interrupting", or "controlling". I am just</div><div>suggesting to be allowed to set a break-point on some unique function.</div><div><br></div><div><br></div><div>I finally dug deeper into the issue and figured out this is actually a problem with DWARF</div><div>encoding, or the way that type info is encoded by GCC into DWARF and decoded by</div><div>__gcc_personality from DWARF. (there is a comment somewhere in the LLVM documentation</div><div>that IIRC seems to imply the problem is with the Types parameters to llvm.eh.select, but</div><div>that is incorrect, the problem is deeper than that, it is with the underlying DWARF tables).</div><div><br></div><div>In short the problem is that there is an ambiguity between a cleanup handler having</div><div>an Action Table entry that looks like</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>.byte<span class="Apple-tab-span" style="white-space:pre"> </span>1<span class="Apple-tab-span" style="white-space:pre"> </span>;; Type = 1 (ie #1 entry in Types Table)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>.byte<span class="Apple-tab-span" style="white-space:pre"> </span>0<span class="Apple-tab-span" style="white-space:pre"> </span>;; Next = 0 (ie none, ie this is the list terminator for this try-statement)</div><div>together with a corresponding Types Table entry #1 that looks like</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>.long<span class="Apple-tab-span" style="white-space:pre"> </span>0<span class="Apple-tab-span" style="white-space:pre"> </span>;; RTTI pointer == NULL</div><div><br></div><div>and a user explicit try-catchall statement which also contains the exact same DWARF</div><div>encoding.</div><div><br></div><div>Instead a user explicit catch-all should have an explicit entry in the Types Table (perhaps</div><div>"void" could be the "user explicit match anything" marker) rather than containing the NULL value.</div><div><br></div><div>Right now "cleanups" look to __gcc_personality exactly like "user explicit catch-all", so there</div><div>is no way for __gcc_personality to tell that something will not be caught (if an exception will</div><div>only go through cleanups all the way out past main, it "looks" to __gcc_personality that it is</div><div>actually being caught by "catch-all"s, so __gcc_personality currently cannot figure this out</div><div>until after the stack is entirely unwound and the user is then SOL).</div><div><br></div><div><br></div><div><br></div><div>Peter Lawrence.</div></body></html>