Bug 489100 - No cross-DLL exceptions in mingw32 compilers
No cross-DLL exceptions in mingw32 compilers
Status: CLOSED ERRATA
Product: Fedora EPEL
Classification: Fedora
Component: mingw32-gcc (Show other bugs)
el5
All Linux
low Severity high
: ---
: ---
Assigned To: Richard W.M. Jones
Fedora Extras Quality Assurance
ActualBug
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-07 10:38 EST by Wolfgang Glas
Modified: 2011-12-29 08:54 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-12-29 08:54:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
A testcaes, which trowas an exception across a DLL boundary. (1003 bytes, application/x-gzip)
2009-03-07 11:06 EST, Wolfgang Glas
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 34684 None None None Never
Debian BTS 451438 None None None Never

  None (edit)
Description Wolfgang Glas 2009-03-07 10:38:01 EST
Version 4.3.2-12 of EPEL's version of the moingw32 cross-compiler do not support cross-DLL exceptions.

I've attached the gcc bug report below. This make running a non-trivial C++ program impossible an renders the mingw32 toolchain unusable for real-world C++ programs.

The mingw-w64 toolchain has solved this problem by supplying a shared libgcc, hopefully the mingw32 toolchain will follow this approach in the near future.

Please keep on your tremendous work on providing the ming32 toolchain in the EPEL.

  TIA,

    Wolfgang
Comment 1 Levente Farkas 2009-03-07 10:46:45 EST
can you give us a little bit more detail!?
anyway there is _not_ any kind of standard c++ exception on windows each compiler has it's own exception handling. so it you use gcc for every dll what you use than it'll work. more detail here:
http://lists.fedoraproject.org/pipermail/fedora-mingw/2008-November/000039.html
Comment 2 Wolfgang Glas 2009-03-07 11:06:50 EST
Created attachment 334400 [details]
A testcaes, which trowas an exception across a DLL boundary.

This testcase throw an exception from iside a DLL an catches it in the main program. The generated 64 bit executables of mingw-w64 are working as expected.

The 32bit executables fail with

terminate called after throwing an instance of 'MyException'

BTW, I'm only using C++ programs which are all compiled by the same version of gcc.
Comment 3 Richard W.M. Jones 2009-03-07 11:11:10 EST
Thanks for the test case - it's definitely good to have a way to test whether what we're
doing is correct.

Do you know about the (to me) "mysterious" DLL that gcc 4.4 installs?

/usr/i686-pc-mingw32/sys-root/mingw/bin/libgcc_s_sjlj-1.dll

Does it help, hinder or is it irrelevant?
Comment 4 Wolfgang Glas 2009-03-07 11:24:02 EST
According to my experience with mingw-w64, which is gcc-4.4 based, this DLL is referenced by all my C++ DLLs compiled with mingw-w64 and to my knowledge this DLL is the key to cross-DLL exception handling. (contains some _Unwind_* export  functions...)

Since I'm not a specialist in this area you might ask the mingw-w64 people for further explanations, since these guys seem to be the driving force behind the gcc-4.4/mingw integration.
Comment 5 Kevin Kofler 2009-03-07 21:47:46 EST
> Do you know about the (to me) "mysterious" DLL that gcc 4.4 installs?
> /usr/i686-pc-mingw32/sys-root/mingw/bin/libgcc_s_sjlj-1.dll
> Does it help, hinder or is it irrelevant?

That's a shared libgcc (plus, it's using sjlj, not DWARF2 which currently doesn't work across DLLs unless this was solved somehow recently), so it should fix the issue.

Note that the bug report was about 4.3.2, not 4.4, so it's quite possible 4.4 fixes it.

One thing to check is whether static or shared libgcc is the default. If it's static, you'll also need to compile both the DLL and the executable with -shared-libgcc to make it work.
Comment 6 Gianluca Sforna 2009-03-09 03:56:19 EDT
AFAIK this problem is one of the reasons (if not _the_ reason) why the MinGW project is sticking with gcc 3.4.5 instead of upgrading to the 4.x serie.
Comment 7 Richard W.M. Jones 2009-03-09 12:04:50 EDT
(In reply to comment #6)
> AFAIK this problem is one of the reasons (if not _the_ reason) why the MinGW
> project is sticking with gcc 3.4.5 instead of upgrading to the 4.x serie.  

It's Fedora policy to follow upstream (and fix upstream if it's
broken!)
Comment 8 Wolfgang Glas 2009-03-09 12:31:45 EDT
I'm currently trying the gcc-4.4 based mingw-w32 toolchain from the mingw-w64 project. As with their 64bit toolchain they solved the cross-DLL exception problem there by introducing libgcc_s_sjlj-1.dll.

However, gcc-4.4 seems to introduce some new instabilities I'm currently trying to trace. So I think everybody would be happy if the fedora mingw team and the mingw-w64 people could join their forces to make gcc-4.4+mingw a success story ;-)
Comment 9 Gianluca Sforna 2009-03-10 03:57:46 EDT
(In reply to comment #7)
> It's Fedora policy to follow upstream (and fix upstream if it's
> broken!)  

My remark was not intended to be a proposal to downgrade, just a statement about why this was a more or less expected problem. If we can fix the issue, good, it will show a real benefit of Fedora-MinGW effort.

However, given how much time this problem is around, I wonder if it's that easy to fix... Do we have resident (@redhat) experts in the field to ask?
Comment 10 Kevin Kofler 2009-03-10 05:04:24 EDT
It is already fixed, see comment #8. It will be fixed in Fedora when the packages will be upgraded to 4.4. (In Rawhide, that already happened.)
Comment 11 Wolfgang Glas 2009-03-15 15:59:42 EDT
Please note, that the mingw-w64 people have now fixed a nasty stability problem in their mingw-w64 distribution (not affecting 32 bit binaries), so gcc-4.4 for Windows x8 and x64 seems to be quite stable now ;-)
Comment 12 Hin-Tak Leung 2009-08-29 21:31:13 EDT
Note upstream at mingw has released some 12/13 patches for gcc 4.4.0 in June, and also recommend dwarf2 instead of sjlj...
Comment 13 Aravind vijayan 2011-12-29 08:54:43 EST
I believe this bug was fixed in an upstream:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34684, so let me change the flag as:CLOSED/ERRATA , feel free to reopen this bug if u still experiencing this problem.  



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Note You need to log in before you can comment on or make changes to this bug.