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

[Ranjit Mathew <rmathew at gmail dot com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brian Dessent wrote:
> Ranjit Mathew wrote:
> 
>> -#define DWARF2_UNWIND_INFO 0
>> +#define DWARF2_UNWIND_INFO 1
> 
> This makes no sense at all.  DW2 EH is seriously broken under
> cygwin/mingw, and it's not clear that this is even fundamentally fixable
> (e.g. the situation of throwing an exception in a callback from third
> party code that doesn't use DW2 like the win32 API.)  Someone posted on
> the mingw list recently with a testcase showing even further breakage in
> DW2 EH when throwing across a DLL boundary.  Flipping this switch should
> be the *last* step that happens after all these other problems are
> fixed, not the first step.  SJLJ is still the only sane default for
> cygwin/mingw.

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.

I don't think I should be submitting a single "big bang"
patch (if ever) that resolves all problems with DW2 EH
for MinGW. I will have a close to zero chance of it being
reviewed and accepted. I personally also like to keep the
number of local changes to the GCC sources as few as
possible, especially if such changes can be applied to
the FSF tree without adversely affecting anything else.

Now on to your other objections about DWARF-2 based EH.

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/

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.

Would you expect the exception to be caught by bar() or foo()?

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.)

As far as I can tell, the GUI callback "problem" with DW2 EH is
not insurmountable and can be done by a dedicated hacker with
enough knowledge of the stuff involved.

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.

Thanks,
Ranjit.

- --
Ranjit Mathew      Email: rmathew AT gmail DOT com

Bangalore, INDIA.    Web: http://rmathew.com/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEkVyaYb1hx2wRS48RAr8OAKCApieu42og0sRuW8WSVDsVspRZlwCgoyd4
5NMc58ZNWawLH2NbYzPPFh0=
=lGEX
-----END PGP SIGNATURE-----