This is the mail archive of the
mailing list for the Cygwin project.
Re: Slowness problem due to sjlj-exceptions for Octave
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
I researched by the Google again I found you have already written the
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
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.
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.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html