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

[alvaro <alvaro.segura@xxxxxxxxx>]

Thanks again for the details.
I increasingly realize the effort made to adapt gcc to Win32.

So let me just say that this issue would be worth investigating. In the 
unlikely event that I come up with a solution I'll let you all know :-)

Alvaro

(naive comment: this reminds me of some C++ plugin systems that 
automatically register themselves in a single factory object existing in 
the main exe whenever a plugin DLL is loaded. The DLLs have global 
constructors that manage to, on-load, find the unique global factory 
object and register into it. I'm still not sure how)


Brian Dessent escribió:
> 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
> 


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