<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
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>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: hosking@cs.purdue.edu<br>Date: Sun, 2 Jan 2011 18:19:36 -0500<br>To: jay.krell@cornell.edu<br>CC: m3devel@elegosoft.com<br>Subject: Re: [M3devel] how to use gcc exception/unwind support?<br><br>
<meta http-equiv="Content-Type" content="text/html; charset=unicode">
<meta name="Generator" content="Microsoft SafeHTML">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> </body>
</html>