From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28896 invoked by alias); 8 Nov 2002 01:10:15 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 28888 invoked from network); 8 Nov 2002 01:10:15 -0000 Received: from unknown (HELO devserv.devel.redhat.com) (66.187.233.200) by sources.redhat.com with SMTP; 8 Nov 2002 01:10:15 -0000 Received: (from jakub@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id gA819ga16699; Thu, 7 Nov 2002 20:09:42 -0500 Date: Thu, 07 Nov 2002 17:10:00 -0000 From: Jakub Jelinek To: Mark Mitchell Cc: Richard Henderson , Geoff Keating , "zack@codesourcery.com" , "jakub@redhat.com" , "aldyh@redhat.com" , "gcc-patches@gcc.gnu.org" , "jason@redhat.com" Subject: Re: [basic-improvements] try/finally support for c/c++ - more tests Message-ID: <20021107200942.X10988@devserv.devel.redhat.com> Reply-To: Jakub Jelinek References: <20021107234453.GE26257@redhat.com> <133260000.1036714743@warlock.codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <133260000.1036714743@warlock.codesourcery.com>; from mark@codesourcery.com on Thu, Nov 07, 2002 at 04:19:03PM -0800 X-SW-Source: 2002-11/txt/msg00527.txt.bz2 On Thu, Nov 07, 2002 at 04:19:03PM -0800, Mark Mitchell wrote: > > What you're asking for is that we have .eh_frame data, but that > > we go look somewhere else when it comes time to decide if the > > frame wants to handle exceptions. This look-aside will have to > > happen for each and every call frame, because we don't know which > > frames are written in C and which aren't. > > Couldn't it get a bit in its frame info to say whether or not it calls > pthread_cleanup_push? That would make the check pretty cheap. (I'm > not nearly as familiar as you with the format of that data; it might > well be that there's no place to put that bit.) You mean statically into .gcc_except_table, or dynamically? Statically could be doable through some builtin and some hacks, dynamically would be way harder. > It has somewhat fancy semantics. For example, you can catch > floating-point exceptions this way and other things that would be > signals in UNIX. They have a "__leave" keyword; they have exception > handling (as well as cleanups) and they have ways to say whether you > keep unwinding, or stop where you are, when you hit the handler. > > The aysnchronous exception aspect of their stuff is particularly > interesting. > > It's partly because of Microsoft's stuff that I'm so nervous about > this feature. Their semantics are not always what people expect, but > ours probably won't match theirs, and the next thing that will happen > will be that people will want to port "structured exception-handling" > code to GCC, and then we'll be in trouble. That's why the proposal is about __try/__finally only, not __except where it is e.g. not clear at all what happens if you throw in C++ and __except control expression returns -1. At least from what I read in MSFT docs on the web, their __try/__finally matches Aldy's patch. > I would prefer longjmp_unwind; that's something we're supposed to > have anyhow, and it would be very useful in making existing C > libraries play more nicely with C++, so implementing that would be > a definite win. longjmp_unwind would be good to have. But __builtin_setjmp has higher runtime overhead than __try/__finally for pthread_cleanups (especially on some architectures __builtin_setjmp is really expensive), plus unless I misunderstood how longjmp_unwind is supposed to work, longjmp_unwind needs to be passed address to the youngest jmp_buf on the stack, which means maintaining a chain of nested jmp_buf's on the stack with the head of the chain in some TLS variable (Richard, please correct me if you have a better idea). __try/__finally can well interact with longjmp_unwind - longjmp_unwind would just call all the __finally blocks while unwinding to the longjmp_unwind target. Jakub