Larry Hall wrote: > >True but the way I read that conversation was that DWARF2 >EH worked if callbacks weren't used or would work with >callbacks so long as -fexceptions was used. Maybe I read >that incorrectly though.
That is correct. Maybe we can convince ReactOs to release a win32api built with -fexceptions and DW2 unwind tables. >> >>My goal is to build gcc/g++ that use Dwarf2 EH. A >>compiler with working EH will be able to run my test >>program without aborting. So far I have built several >>versions of gcc, all of which have the abort() EH, >>which is equivalent to having _no_ EH in practical >>terms. >> >>Maybe Danny Smith has some thoughts about this, since >>he has apparently been at least partially successful >>in getting DWARF2 EH to work on cygwin. > > >Yes, I expect he'll chime in. > <ding-dong-lurker.wav> FWIW, Dwarf2 unwind worked without any complaints (that I am aware of) from cygwin users in a GCC-3.2 (cygming special) release. One of the two DW2 bug reports by mngw users (stdcall vs fomit-frame-pointer vs -mno-accumulate-outgoing-args) has been fixed in GCC. The other (callbacks that throw exceptions from a foreign function) has not A 4.0 patch to enable DW2 unwind is at: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01989.html GCC is now in Stage 3 of development cycle (regression fixes only) I plan to submit a revised patch when 4.0 branches. So maybe 4.1 > >>Another question for anyone at all: any ideas why sjlj >>is so crap-tastically slow on cygwin? I can't believe >>that sjlj EH has nearly such a huge hit on other >>targets. If sjlj it is the sole perpetrator of the >>slowdown, then it is doing a very very effective job >>of slowing things down. > Depends. If you're app makes only limited use of exceptions, sjlj can be more efficient. However, since operator new can throw exceptions, the cost of sjlj can add up very quickly. I think the default use of the simple new-based allocator in gcc-3.4.x libstdc++ (rather than a more efficient pool allocator) also compounds the problem. I wouldn't blame everything on sjlj. C programs that do any file I/O are also crap-tastically slow on windows compared to glibc targets. Danny -- 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/