X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
From: Tatsuro MATSUOKA <matsuoka AT mol DOT nagoya-u DOT ac DOT jp>
To: cygwin AT cygwin DOT com, brian AT dessent DOT net
Cc: matsuoka AT nuce DOT nagoya-u DOT ac DOT jp
Date: Thu, 6 Sep 2007 08:23:43 +0900
Subject: Re: Slowness problem due to  sjlj-exceptions for Octave
In-Reply-To: <46DE0C86.61C0ABB0@dessent.net>
References: <20070905080321 DOT 29259AB0 DOT matsuoka AT mol DOT nagoya-u DOT ac DOT jp> <46DE0C86 DOT 61C0ABB0 AT dessent DOT net>
Message-Id: <20070906082343.87689790.matsuoka@mol.nagoya-u.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: nPOP Ver 1.0.9
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT 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

Thank you Brian

>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.
>

I researched by the Google again I found you have already written the 
the following.

http://cygwin.com/ml/cygwin/2005-04/msg01071.html

I understood the reason of adaption of the sjlj exception on cygwin.  
For the octave, the sjlj slowness is so large.  My selection is the 
dangerous but the fast way.

My octave web
http://www.geocities.jp/tmacchant/

I think it is better that I keep the my binary on my web but post on 
the new binary package on the cygwin.  I do not want to build the 
octave by the gcc in the cygwin package because it is too slow to use.

 
>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 a

Do you mean standalone as standalone from cygwin1.dll?  Mingw binary 
depends on msvcrt.dll.  In this sense the binary built by mingw GCC 
is not standalone. Recently the mingw GCC4.2.1's were released.  

http://sourceforge.net/project/showfiles.php?group_id=2435

The both sjlj and dwarf2 versions are prepared. I am not expert of 
mingw. Even in mingw, selection of sjlj or dwarf2 is not meaningless.

On the other hand, it is grateful that the effort of the fast 
exception system has been continued.  I hope this will be success as 
early as possible and it will be necesarry use the fast but not safe 
exception handling GCC for octave building.

Sincerely

Tatsuro Matsuoka  



--
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/