***BOGO*** Re: [Mingw-users] MinGW gcc 3.x, 4.x and exceptions

[Brian Dessent <brian@xxxxxxxxxxx>]

alvaro wrote:

> I tested gcc 3.4.5 and found no problem: an exception thrown by a DLL
> (loaded on demand with LoadLibrary) was caught by the main exe. Not sure
> if problems are only in DLLs linked with import libs.
> 
> Now, in gcc 4.x, they say in order to throw exceptions across DLLs you
> must link a shared libgcc. IMHO this kind of breaks the MinGW philosophy
> of not depending on additional DLLs (see the home page), possibly the
> main difference with cygwin and one of the reasons I prefer MinGW.
> 
> I would say it is *very* important to keep MinGW this way and still
> support exceptions. If that implies using the "old" SJLJ system, I
> wouldn't mind. I can admit a little performance loss. If 3.x can do it,
> why can't 4.x?

The problem has nothing to do with DW2 vs SJLJ; they are both equally
affected.

The problem is that the 3.4 compiler has a very ugly local hack to allow
this, and the 4.x one does not.  At issue is the fact that when you
statically link libgcc you end up with two copies (instances) of it
linked into the running process: the libgcc statically linked into the
.exe and the static libgcc linked into the .dll.  There is no
communication between them, and these two unwinders are not aware of
each other, thus a thrower in one module will not see any of the catcher
frames registered in the other unwinder.  The throw code will have no
option but to terminate with an uncaught exception, because there is no
matching catch handler registered.  If libgcc is a DLL then there is
only one instance of it in the process, so all the exception
registrations for all modules in the process go through one place and
everything works.

In gcc 3.4 this was handled by using a very ugly hack involving Win32
Atoms in order to establish a global state between all the disparate
unwinders; see w32-sharedptr.{c,h}.  This hack was never accepted
upstream, and the internals of gcc changed too much in the 4.x
development phase for this method to work with gcc 4.x.

So it's a technical limitation, not anything to do with MinGW policy. 
And this is not unique to MinGW -- many other platforms have degraded or
broken exception handling unless libgcc is shared, for the same
reasons.  That is likely another reason that no such patch would be
accepted upstream, because this is not a MinGW specific issue.

Brian

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users