From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3335 invoked by alias); 9 May 2003 10:16:18 -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 3324 invoked from network); 9 May 2003 10:16:17 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 9 May 2003 10:16:17 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h49AGEH30594; Fri, 9 May 2003 06:16:14 -0400 Received: from redhat.com (IDENT:dkCsLnSKDre1CkZejQugP2OuDbAaDTx8@vpn50-19.rdu.redhat.com [172.16.50.19]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h49AGDI20040; Fri, 9 May 2003 06:16:14 -0400 Received: (from aph@localhost) by redhat.com (8.11.6/8.11.0) id h49AGCR19442; Fri, 9 May 2003 11:16:12 +0100 From: Andrew Haley MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16059.32748.60695.113159@cuddles.redhat.com> Date: Fri, 09 May 2003 10:16:00 -0000 To: "Ranjit Mathew" Cc: gcc@gcc.gnu.org Subject: Re: __attribute__((cleanup(function)) versus try/finally In-Reply-To: References: X-SW-Source: 2003-05/txt/msg00876.txt.bz2 Ranjit Mathew writes: > > > > > The __finally block is executed in case of both "normal" C++ > >exceptions > > > > > as well as "faults" such as accessing a NULL pointer, dividing by > >zero, > > > > > etc. > > > > > > > >And your point is... ? Libjava does this for dwarf2 EH on Linux. > > > > > > Yes, I know (http://gcc.gnu.org/java/port-signals.html). > > > >Oh no, that page is way, way out of date. I must rewrite it. > >There's not even any mention of MD_FALLBACK_FRAME_STATE_FOR, which is > >the crucial part of the job. > > Maybe laymen aren't supposed to be implementing MAKE_THROW_FRAME for > libgcj ;-), but I think it should at least be pointed out that the crucial > reasons > the given example works *at all* are that: > > 1. Linux does not care if the signal handler returns or not (unlike > Windows). Actually, the C standard is quite explicit about this: signal handlers may return either by a return statement of calling longjmp(). Maybe the Windows version of longjmp() does some magic to make this work. > 2. A proper MD_FALLBACK_FRAME_STATE_FOR definition for Linux/x86 Or for any other OS, for that matter. The trouble with doing MD_FALLBACK_FRAME_STATE_FOR for other OSs is that it necessarily requires knowledge of kernel data structures. > ensures that unwinding works through the intervening signal > handler frame when a "throw" occurs, instead of aborting the > process with an uncerimonious "abnormal program termination" as > would have happened otherwise. Actually, that example was written before MD_FALLBACK_FRAME_STATE_FOR, as was the whole page. That's why it's so inaccurate. Andrew.