<html><head><base href="x-msg://1137/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>I don't understand why we can't continue to use the same approach we had with gcc 4.3, except utilizing the gcc unwind mechanisms.</div>
<br><div><div>On Jan 2, 2011, at 8:57 PM, Jay K wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div class="hmmessage" style="font-size: 10pt; font-family: Tahoma; ">I understand partly and agree as far as I understand.<br><br><br>For example..I think it is important, interesting, and subtle that C++ throw resolves to a function call generated<br>by the C++ front end, with the implication that the backend has a certain ignorance as to how it works,<br>with the additional implication that we can (continue to) call our own function to throw/raise an exception.<br><br><br>Where I get confused however is esp. resolving "TRY_CATCH", that the backend is given<br>a list of handlers. What is a "handler"?<br><br><br>And then..there is also a list of types..but ah, I think I start to see.<br>I think the list of types are meaningless in tree/gimple, only a C++ thing,<br>and the handlers are probably merely pieces of code to connect control flow edges too?<br><br><br>I have another idea though...I was thinking...if this is true, if it is just about flow graph...<br>I think there might be two useful intermediate steps toward implementing this.<br><br><br>The first implementation would not change the compiler at all, just write the new RTException.m3, and<br>only work with no optimizations. Get this to work.<br><br><br>The second implementation would sprinkle volatile on all locals in functions<br>that have "try". Or heck, just as an *experiment* put volatile everywhere like<br>it was before, enable -O3, see that that seems to work.<br><br><br>Neither of those two versions would likely be commited, except maybe requiring non-default compiler switches.<br><br><br>And then tell the backend about the control flow via the eh stuff in tree.def, and enable optimizations.<br><br><br>Make some sense?<br><br><br>The first step is at least a good necessary/easy experiment I think.<br> Not so easy, but necessary anyway.<br><br><br>Furthermore..give me a bit more time to consider all this, instead of going<br>back to 4.3?<br><br><br>Granted, SPARC32_SOLARIS might not ever get this.<br>You know -- what is the availability of the gcc unwinder on Solaris?<br></div></span></blockquote><div><br></div><div>But we do use gcc as the M3 backend on Sparc, so not a problem.</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div class="hmmessage" style="font-size: 10pt; font-family: Tahoma; ">Surely it is there if you use gcc. But if you use cc?<br><br><br>Then to wonder, how does Sun CC work?<br><br><br>But I think if we had this working on Darwin, and then Linux, and then FreeBSD,<br>and then OpenBSD and NetBSD, maybe Cygwin, it wouldn't be so awful for Solaris, et. al. to still use setjmp.<br>NT386 could easily remain with setjmp a while too.<br><br><br> - Jay<br><br><br><br><hr id="stopSpelling">From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>Date: Sun, 2 Jan 2011 18:19:36 -0500<br>To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>CC:<span class="Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Subject: Re: [M3devel] how to use gcc exception/unwind support?<br><br>My take was that we would use the unwind support with RTExStack along with recording the flow constraints for the IR. They were never that tricky.<div><br><div><div>On Jan 2, 2011, at 3:29 AM, Jay K wrote:</div><br class="ecxApple-interchange-newline"><blockquote><span class="ecxApple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; font-size: medium; "><div class="ecxhmmessage" style="font-size: 10pt; font-family: Tahoma; ">Tony et. al. do you have much idea already in mind of what using gcc exception and/or unwind support would look like?<br><br><br>In particular, do you think we could/should/would use<br>TRY_CATCH_EXPR, TRY_FINALLY_EXPR? I'm not sure (see below).<br><br><br>Do you understand the difference between WITH_CLEANUP_EXPR and TRY_FINALLY_EXPR?<br>I don't. Maybe WITH_CLEANUP_EXPR captures a common case is very similar?<br><br><br>Regarding TRY_CATCH_EXPR, TRY_FINALLY_EXPR, they sound very promising.<br>But does CATCH_EXPR provide the right construct for deciding to catch or not,<br>and passing the exception properly to the handler?<br><br><br>Or should we use RTExStack nearly or completely unchanged, but:<br> 1) have it call libgcc/libunwind, via interface RTStack.<br> 2) in the backend mimic TRY_CATCH_EXPR, TRY_FINALLY_EXPR's affects/pessimisations<br> on the control flow graph and such?<br> <span class="ecxApple-converted-space"> </span><br><br>Related question is how to model throwing an exception in the backend.<br>This I had looked at even less (e.g. trying to understand how g++ uses this stuff) but is clearly important.<br>g++ clearly sometimes calls __cxa_throw, not clear if it always does.<br>Not clear it does anything else in terms of informing the backend. It looks like not.<br><br><br> - Jay<br><br></div></span></blockquote></div><br></div></div></span><br class="Apple-interchange-newline"></blockquote></div><br></body></html>