Re: [MinGW] Allow Building GCC with --disable-sjlj-exceptions

[Brian Dessent <brian at dessent dot net>]

Ranjit Mathew wrote:

> To find out the cause of the ICE was a non-trivial task
> for me and I think having this patch in the FSF tree will
> help the next hacker who tries to build GCC for MinGW with
> DW2 EH.

Then it should be conditional on --disable-sjlj-exceptions, i.e. only
enabled for those adventurous souls that are brave enough to build such
a broken compiler.  You can't just go changing the default unwinding
like this unconditionally.

> For throwing exceptions across a DLL boundary, a patch
> has existed for quite some time. For example, see the
> "w32-shared-ptr.{h,c}" files in:
> 
>   http://gcc.gnu.org/viewcvs/branches/cygming332/gcc/config/i386/

I assume you're referring to the patchs by Danny Smith, which are
inluded in the mingw distribution.  Yet even with this patch things are
still broken, as demonstrated by the testcase here:
http://marc.theaimsgroup.com/?t=114984401200003&r=1&w=4

> As for throwing exceptions across third-party-compiled code,
> I am not sure if even SJLJ EH can help in a case like the
> following, for example:
> 
>   1. GCC-compiled code foo() with "catch all" handler calls
>   third-party-compiled code bar().
> 
>   2. bar() with "catch all" handler calls GCC-compiled code
>   snafu().
> 
>   3. snafu() throws an exception.

Obviously that would be undefined, but that's not what I'm talking
about.

> The canonical example for the Win32 callback problem with
> DW2 EH is:
> 
> https://sourceforge.net/tracker/?func=detail&atid=102435&aid=616059&group_id=2435
> 
> In this case the same "problem" with SJLJ EH that I point above
> is the feature that allows it to score over DW2 EH. (Never mind
> that expecting to handle exceptions thrown within GUI callbacks
> is a weird programming style in its own right. For example, Java
> normally has a separate event-handling thread and this kind of
> coding will not work with it.)

Whether it's weird or not, it is apparently common enough that it causes
problems for users, and necessitates SJLJ still being the default.

> SJLJ is *quite* slow compared to DW2 EH, penalising the code even
> when no exceptions are thrown. For better or for worse, Java code
> is littered with exceptions throwers and catchers. GCJ has also
> come to depend on DW2 unwind information (via the _Unwind_Backtrace()
> method of GCC) for stack traces and to find out caller methods and
> classes. We *need* DW2 EH for MinGW to work if we are to have any
> hopes for Java on this target.

This I agree with.  But just #defining DWARF2_UNWIND_INFO when the code
is still very broken does not seem like a good idea.

Brian