From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-73643-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 12080 invoked by alias); 8 May 2003 18:02:27 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 12072 invoked from network); 8 May 2003 18:02:26 -0000
Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51)
  by sources.redhat.com with SMTP; 8 May 2003 18:02:26 -0000
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225])
	by mail-out2.apple.com (8.12.9/8.12.9) with ESMTP id h48I2QQd008737
	for <gcc@gcc.gnu.org>; Thu, 8 May 2003 11:02:26 -0700 (PDT)
Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T6213d81ca2118064e13f4@mailgate1.apple.com>;
 Thu, 8 May 2003 11:02:05 -0700
Received: from apple.com (mrs1.apple.com [17.201.24.248])
	by scv1.apple.com (8.12.9/8.12.9) with ESMTP id h48I2HF9018728;
	Thu, 8 May 2003 11:02:17 -0700 (PDT)
Date: Thu, 08 May 2003 18:02:00 -0000
Subject: Re: __attribute__((cleanup(function)) versus try/finally
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: jason@redhat.com, gcc@gcc.gnu.org
To: Ranjit Mathew <rmathew@hotmail.com>
From: Mike Stump <mrs@apple.com>
In-Reply-To: <3EB8DD9A.2050100@hotmail.com>
Message-Id: <341C605E-817F-11D7-BD07-003065A77310@apple.com>
Content-Transfer-Encoding: 7bit
X-SW-Source: 2003-05/txt/msg00815.txt.bz2

On Wednesday, May 7, 2003, at 03:19 AM, Ranjit Mathew wrote:
> Now I have an issue somewhat related to this
> discussion that I hope someone would be able to
> shed some light on: on Windows, the Cygwin/MinGW
> targets have had to give up on DW2 EH in favour of
> SJLJ purely because exceptions could not be
> thrown from a callback function, across the
> Windows Event Dispatcher stack to the handler
> of the exception.

This can be made to work given an integrated sjlj/dwarf2 EH scheme.  At 
transition points into and out of code compiled by other compilation 
systems (or -fno-exception code), we introduce a sjlj cleanup point 
there.  For, take for example:

foo() {
   DispatchMessage();
}

we have to know that DispatchMessage is going to go to `outside', 
imagine if you will:

#pragma gcc EH doesnt have unwind tables: DispatchMessage

foo() {
   ...
   DispatchMessage();
   ...
}

then it is a simple process to generate:

foo() {
	...
	sjljtry {
		DispatchMessage();
	} catch (...) {
		rethrow;
	}
	...
}

instead.  We can get back `into' the unwind tables by doing the lj back 
to this point.

> In fact, this seems to be a fundamental limitation
> of the DW2 EH mechanism and not just on Windows.

An unimplemented feature, I'd say, not a fundamental limitation.  
Though, such a change would be probably have ABI impact, as only the 
enhanced thrower would be able to fall back to doing the throw when it 
runs out of unwind information.