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

[Tony Hosking]

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.

On Jan 2, 2011, at 8:57 PM, Jay K wrote:

> 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?

But we do use gcc as the M3 backend on Sparc, so not a problem.

> 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/26a7ce34/attachment-0002.html>