Re: [Mingw-users] GCC 4.3.0 20080502 (alpha) Released - Please help us test it!

[ATS <asteinarson@xxxxxxxxx>]

> > How do you think this effects qt or wxwidgets programs? If either use
> > the underling win32 native widgets, I suppose they could be candidates
> > for being broken?
> 
> Can anyone confirm that QT, wxWidgets, or some other popular toolkit or 
> native Windows program depends on being able to throw C++-language 
> exceptions through the Win32 callback callers?

wxWidgets does not throw exceptions itself. In some builds it uses 
an external STL library that can throw (and wxString would then be 
based on STL, danger, danger). QT is not so closely coupled to the
Win32 event loop I believe (does not rely on native widgets).

Given that one knows about all dangers with C++ exceptions and callbacks, 
I think cross platform developers who build for different compilers 
are quite conservative about using C++ exceptions. 

One thing that I've found very useful is to translate Unix signals 
into C++ exceptions (from GCC 4.2 this is supported on Linux). One
gets semantics very close to what MS VC++: 

   try {
      *(int*)0 = 0;
   } catch ( SignalException* pse ) {
      printf( "Exception condition: %s\n", pse->GetReason() );
   }

This provides a safety net when loading plugins or other running other 
code that one has not built oneself. Without a mechanism like this, the
app is doomed whenever 3rd party code does a NULL pointer access or 
divide by zero. For me this is a crucial feature. 

(the code above can be built with either Linux GCC or Win32 MSVC, linked 
to an OS specific library, relying on either signals or SEH). 


> 
> If we need to take some alternate course of action, that is fine; but I 
> need some evidence first of the potential negative impact of this.
> 

As I see it the either-or debate (SJLJ/DWARF) is a bit limiting. SJLJ
is slow because it does a complete CPU state save (FPU, MMX?, SSE?). 
This is needed when saving thread context. However, jumping into a 
catch block, it is way too much. We really only need to save/restore
EBP, ESP and EIP into a linked list of handlers. Restoring FPU state 
and everything else as before the 'catch' block is not necessary. The
compiler could have a 'register barrier' before the catch code, so 
that it knows only EBP, ESP and EIP is reliable.  

In short, a very lightweight context is saved. A full X86 CPU context 
is large these days.


> Then I also need to know what the alternative is.  There's no real point 
> in making a release if we know the ABI will be broken a few months 
> later.  Would people prefer that the final release is delayed?  Or 
> perhaps it should remain in a 'Tech Preview' state until this problem is 
> resolved?
> 

My vote would be for a light weight state exception mechanism for Windows. 
It is not affected by foreign frames, is quite fast and small. It would
be per thread. A decent interface / binding with SEH on top of that would 
be a bonus.

Note: For java that catches a lot of null pointer exceptions (This is 
a signal or SEH), some binding between SEH and C++ exceptions is needed.
There is not a try/catch block around every java object pointer access, 
just a handler that get's invoked when the CPU accesses invalid memory, 
and this is neatly converted to a Java exception).

Regards
// Arne Steinarson


> I'm willing to be convinced to do something other than what's been 
> planned, which is part of the purpose of this protracted testing and 
> feedback process.  But I need good reasons that include evidence, and a 
> working alternative.
> 
> -------------------------------------------------------------------------
> 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@...
> 
> 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