From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24343 invoked by alias); 7 May 2003 18:23:26 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 24332 invoked from network); 7 May 2003 18:23:26 -0000 Received: from unknown (HELO mx2.redhat.com) (12.150.115.133) by sources.redhat.com with SMTP; 7 May 2003 18:23:26 -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 h47ICrZ25931; Wed, 7 May 2003 14:12:54 -0400 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 h47INPT26604; Wed, 7 May 2003 14:23:25 -0400 Received: from dot.sfbay.redhat.com (dot.sfbay.redhat.com [172.16.24.7]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h47INOM26385; Wed, 7 May 2003 11:23:24 -0700 Received: (from rth@localhost) by dot.sfbay.redhat.com (8.11.6/8.11.6) id h47IKvL08149; Wed, 7 May 2003 11:20:57 -0700 X-Authentication-Warning: dot.sfbay.redhat.com: rth set sender to rth@redhat.com using -f Date: Wed, 07 May 2003 18:23:00 -0000 From: Richard Henderson To: Ranjit Mathew Cc: jason@redhat.com, gcc@gcc.gnu.org Subject: Re: __attribute__((cleanup(function)) versus try/finally Message-ID: <20030507182057.GD8118@redhat.com> Mail-Followup-To: Richard Henderson , Ranjit Mathew , jason@redhat.com, gcc@gcc.gnu.org References: <3EB8DD9A.2050100@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EB8DD9A.2050100@hotmail.com> User-Agent: Mutt/1.4i X-SW-Source: 2003-05/txt/msg00672.txt.bz2 On Wed, May 07, 2003 at 03:49:06PM +0530, Ranjit Mathew wrote: > The same issue was pointed out (albeit in passing) > when Aldy Hernandez had submitted his __try/__finally > patch to GCC for C. And I responded at the time claiming that the semantics of the two extensions are identical. > Since the Win32 API stack does not have DW2 EH > unwind information, the program just terminates > when an exception is thrown (if using DW2 EH). > > SJLJ does not have any such problems. > > In fact, this seems to be a fundamental limitation > of the DW2 EH mechanism and not just on Windows. Yes. Such is the price you pay for not saving all of the registers up front when an exception is *not* thrown. > MD_FALLBACK_FRAME_STATE_FOR looks a bit promising > but how do we generalise it to any "foreign" caller? Eh, MD_FALLBACK_FRAME_STATE_FOR isn't really generalizable. You could perhaps hack it to parse SEH unwind data, but... Another possibility is to give up on unwind-dw2.c entirely and write a new unwinder that uses the SEH bits in the Win32 API directly, all the time. Then (1) you'd be able to unwind through Windows routines and (2) there'd be no "confusion" about the supposed "differences" in try/finally. r~