From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21546 invoked by alias); 7 Nov 2002 23:45:03 -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 21538 invoked from network); 7 Nov 2002 23:45:01 -0000 Received: from unknown (HELO mx2.redhat.com) (12.150.115.133) by sources.redhat.com with SMTP; 7 Nov 2002 23:45:01 -0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id gA7NhNP23834; Thu, 7 Nov 2002 18:43:23 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id gA7Nitl04875; Thu, 7 Nov 2002 18:44:55 -0500 Received: from localhost.localdomain (frothingslosh.sfbay.redhat.com [172.16.24.27]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id gA7NisD11576; Thu, 7 Nov 2002 15:44:54 -0800 Received: (from rth@localhost) by localhost.localdomain (8.11.6/8.11.6) id gA7NirU28995; Thu, 7 Nov 2002 15:44:53 -0800 X-Authentication-Warning: localhost.localdomain: rth set sender to rth@redhat.com using -f Date: Thu, 07 Nov 2002 15:45:00 -0000 From: Richard Henderson To: Mark Mitchell Cc: 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: <20021107234453.GE26257@redhat.com> Mail-Followup-To: Richard Henderson , Mark Mitchell , Geoff Keating , "zack@codesourcery.com" , "jakub@redhat.com" , "aldyh@redhat.com" , "gcc-patches@gcc.gnu.org" , "jason@redhat.com" References: <20021107223902.GA26257@redhat.com> <118010000.1036709447@warlock.codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <118010000.1036709447@warlock.codesourcery.com> User-Agent: Mutt/1.4i X-SW-Source: 2002-11/txt/msg00518.txt.bz2 On Thu, Nov 07, 2002 at 02:50:47PM -0800, Mark Mitchell wrote: > When in C code, and you hit pthread_cleanup_push, call into the runtime > passing the address of the start and end of the function you're in, and > the frame pointer. When unwinding, notice that you're in that PC range > with that frame pointer, and run the cleanups that correspond to that > range. You're guaranteed to be getting these in the right order; as > you unwind you'll always be pulling stuff off the front of the list. I don't like the idea of registering such information at runtime. It is a fact that to unwind through functions at all you have to compile with -fexceptions, otherwise the data in .eh_frame does not exist. And if .eh_frame does not exist, we don't have enough information to find the next call frame. 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. (And before you mention the personality routine, you should note that any frame that does not actually use EH constructs does not have a personality routine and is thus not an indicator of language.) Whereas if we add some sort of EH block primitive to C, the compiler marks which regions need cleanups statically, in read-only data structures, which are examined as normal during the unwind phase. I think your option slows down EH for C++ and Java for no good reason. --- I don't really comprehend the resistance to adding try/finally to C. I never would have guessed that it would have been greeted with anything but "hey that's cool". I apologize to Aldy for getting him into this mess. I really can't think of any solution to the thread cancelation problem that works as cleanly and correctly as try/finally. Yes, I can think of a few hacks that might could be made to work, but that's all they are -- hacks. It's not like we're even breaking new ground on the language front. Microsoft has supported try/finally in their C compiler for years. I can't imagine WG14 being so bull-headed as to define a similar construct that is wildly incompatible with prior art. Of course, Microsoft fails to define their extension in anything even approaching standards legaleese, but I think that we're on safe ground with the basic concept, and if we make all the horrible corner cases undefined we'll still be ok if the future standard does something different. If you continue to be rock solid dead-set against this extension, I guess I'll honor that and think of something else (probably with something akin to longjmp_unwind). That won't happen until I get back from vacation late next week though. r~