Re: Slowness problem due to sjlj-exceptions for Octave

[rridge at csclub dot uwaterloo dot ca (Ross Ridge)]

Dave Korn wrote:
>   Right, so IOW, the SEH support does all the required unwinding for us.
> Ultimately I guess that's the only solution that's going to be both complete
> and correct.

Well, that is essentially the solution MinGW is using now with SJLJ
exceptions.  MSVCRT's longjmp() is implemented using a SEH forced unwind.

Brian Dessent writes:
>Well, assuming that none of these foreign frames do any kind of
>-fomit-frame-pointer style optimizations, it should be possible to
>implement a fallback unwinder that simply ignores the frame and advances
>one frame up and resumes the table-based unwinding.

I thought about the possibilty mixing the two exception handling methods
and having the MinGW try to unwind both the DWARF and SEH frames in
parallel.  Unfortnately, because they do use FPO, I think the best you
can do is unwind DWARF frames until you get to the callback and then
unwind SEH frames.  I don't think there's anyway you can reliably pick
up the DWARF frames again, and so it wouldn't be a better solution.

>And that's what (I thought) the recent w32-unwind.h contribution in
>4.3 does, but I could be wrong.

It looks like it's a crude hack for the specific problem of unwinding
through "signal handlers".  It's dependent on both specific instruction
sequences used in the operating system code that calls these handlers
and the layout of their stack frames.  I wouldn't be surprised if it
doesn't work on Win9x, checked builds of Windows XP, Wine or in some
other context that the author might not have tested it on.

					Ross Ridge


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