[M3devel] how to use gcc exception/unwind support?

[Jay K]

I understand partly and agree as far as I understand.


For example..I think it is important, interesting, and subtle that C++ throw resolves to a function call generated
by the C++ front end, with the implication that the backend has a certain ignorance as to how it works,
with the additional implication that we can (continue to) call our own function to throw/raise an exception.


Where I get confused however is esp. resolving "TRY_CATCH", that the backend is given
a list of handlers. What is a "handler"?


And then..there is also a list of types..but ah, I think I start to see.
I think the list of types are meaningless in tree/gimple, only a C++ thing,
and the handlers are probably merely pieces of code to connect control flow edges too?


I have another idea though...I was thinking...if this is true, if it is just about flow graph...
I think there might be two useful intermediate steps toward implementing this.


The first implementation would not change the compiler at all, just write the new RTException.m3, and
only work with no optimizations. Get this to work.


The second implementation would sprinkle volatile on all locals in functions
that have "try". Or heck, just as an *experiment* put volatile everywhere like
it was before, enable -O3, see that that seems to work.


Neither of those two versions would likely be commited, except maybe requiring non-default compiler switches.


And then tell the backend about the control flow via the eh stuff in tree.def, and enable optimizations.


Make some sense?


The first step is at least a good necessary/easy experiment I think.
 Not so easy, but necessary anyway.


Furthermore..give me a bit more time to consider all this, instead of going
back to 4.3?


Granted, SPARC32_SOLARIS might not ever get this.
You know -- what is the availability of the gcc unwinder on Solaris?
Surely it is there if you use gcc. But if you use cc?


Then to wonder, how does Sun CC work?


But I think if we had this working on Darwin, and then Linux, and then FreeBSD,
and then OpenBSD and NetBSD, maybe Cygwin, it wouldn't be so awful for Solaris, et. al. to still use setjmp.
NT386 could easily remain with setjmp a while too.


 - Jay



From: hosking at cs.purdue.edu
Date: Sun, 2 Jan 2011 18:19:36 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] how to use gcc exception/unwind support?



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.

On Jan 2, 2011, at 3:29 AM, Jay K wrote:Tony et. al. do you have much idea already in mind of what using gcc exception and/or unwind support would look like?


In particular, do you think we could/should/would use
TRY_CATCH_EXPR, TRY_FINALLY_EXPR? I'm not sure (see below).


Do you understand the difference between WITH_CLEANUP_EXPR and TRY_FINALLY_EXPR?
I don't. Maybe WITH_CLEANUP_EXPR captures a common case is very similar?


Regarding TRY_CATCH_EXPR, TRY_FINALLY_EXPR, they sound very promising.
But does CATCH_EXPR provide the right construct for deciding to catch or not,
and passing the exception properly to the handler?


Or should we use RTExStack nearly or completely unchanged, but:
 1) have it call libgcc/libunwind, via interface RTStack.
 2) in the backend mimic TRY_CATCH_EXPR, TRY_FINALLY_EXPR's affects/pessimisations
  on the control flow graph and such?
   

Related question is how to model throwing an exception in the backend.
This I had looked at even less (e.g. trying to understand how g++ uses this stuff) but is clearly important.
g++ clearly sometimes calls __cxa_throw, not clear if it always does.
Not clear it does anything else in terms of informing the backend. It looks like not.


 - Jay


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110103/76fc5360/attachment-0002.html>