From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13168 invoked by alias); 7 May 2003 13:54:10 -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 13013 invoked from network); 7 May 2003 13:54:09 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by sources.redhat.com with SMTP; 7 May 2003 13:54:09 -0000 Received: from prospero.boston.redhat.com (sebastian-int.corp.redhat.com [172.16.52.221]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h47Ds9i04316; Wed, 7 May 2003 09:54:09 -0400 Received: by prospero.boston.redhat.com (Postfix, from userid 4046) id 54D34F8EB6; Wed, 7 May 2003 09:51:40 -0400 (EDT) To: Ranjit Mathew Cc: gcc@gcc.gnu.org Subject: Re: __attribute__((cleanup(function)) versus try/finally From: Jason Merrill In-Reply-To: <3EB8DD9A.2050100@hotmail.com> (Ranjit Mathew's message of "Wed, 07 May 2003 15:49:06 +0530") References: <3EB8DD9A.2050100@hotmail.com> Date: Wed, 07 May 2003 13:54:00 -0000 Message-ID: User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-05/txt/msg00620.txt.bz2 On Wed, 07 May 2003 15:49:06 +0530, Ranjit Mathew wrote: > Sorry to butt in into this discussion, but I would like to point out that > it would be a BAD idea to name these "__try/__finally" simply because > these are used in the Windows world to deal with Windows Structured > Exception Handling (SEH) and are a language extension introduced by MS > Visual C/C++ (and adopted by other commercial compilers for Windows): >[...] > However unfortunate you consider this situation to be, if GCC introduces > these keywords, it is going to create a lot of confusion. Why would it cause confusion? The VC++ version has the same semantics. > 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. >[...] > 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). Sure. > In fact, this seems to be a fundamental limitation of the DW2 EH > mechanism and not just on Windows. Yes, any callback API would have similar problems if the dispatcher is not compiled with -fexceptions. > So is there a way out of this? > > MD_FALLBACK_FRAME_STATE_FOR looks a bit promising but how do we > generalise it to any "foreign" caller? This is difficult on the x86; you would need to scan back to the beginning of the function and disassemble the function prologue to find out where registers are saved. You could probably use some code from gdb as a starting point. Jason