This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Slowness problem due to sjlj-exceptions for Octave


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]