X-Spam-Check-By: sourceware.org
Message-ID: <46DE0C86.61C0ABB0@dessent.net>
Date: Tue, 04 Sep 2007 18:55:18 -0700
From: Brian Dessent <brian AT dessent DOT net>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Slowness problem due to  sjlj-exceptions for Octave
References: <20070905080321 DOT 29259AB0 DOT matsuoka AT mol DOT nagoya-u DOT ac DOT jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Reply-To: cygwin AT cygwin DOT com
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Tatsuro MATSUOKA wrote:

> My question is why the cygwin uses the slow
> sjlj exceptions instead of
> dwarf2 which was used in old cygwin at the time gcc-3.2 was used.

The choice to ship gcc configured for SJLJ is because it is the only way
to guarantee correct behavior in all cases.  The Dwarf unwinder can't
unwind through a foreign frame.  This means for example if you try to
throw an exception from a function that was called from a Win32 callback
such as the WindProc, it will fail because the frame that exists inside
user32.dll or kernel32.dll (or whatever) has no data in the Dwarf2
tables.  This scenario is not all that far fetched for Windows GUI
programming, so the choice was made to ship gcc safe-but-correct, rather
than fast-but-broken.

There is a patch that has been contributed to 4.3 to fix this, and Danny
Smith includes a backport of it in his 4.2 packages, which is why he is
able to offer both SJLJ and Dwarf2 flavors.  But moving to 4.x has its
own problems, mainly that exception handling across DLLs only works for
shared libgcc, and shared libgcc/libstdc++/etc aren't supported by
upstream gcc on PE.  Danny uses a local patch/hack to build shared
target libs but it's kind of ugly and still quite experimental based on
the bug reports.  For Cygwin we have it a little better because we can
enable shared target libraries by default like *nix distros since we
have a packaging system, so we don't have to worry so much about the
command line mechanics of switching between static/shared libgcc et al. 
But the "w32sharedptr" method used in cygming 3.4.x for suporting EH
with static libgcc is not applicable to gcc 4.x, which means EH across
shared libraries will always be broken in the case of static libgcc et
al.  (The same is true on other platforms like Linux, so it's not a
unique situation.  But MinGW is kind of unique as its users expect to
build standalone apps that don't require DLLs like cygwin1.dll or
libgcc.dll.)

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/