 |
| Prev-20 | Home | Next-20 |
| GCC 4.3.0 20080502 (alpha) Released - Please he... | |
| \ Aaron W. LaFramboise (5 May 2008) | |
| . \ Chris Sutcliffe (5 May 2008) | |
| . . \ Aaron W. LaFramboise (5 May 2008) | |
| . . \ Earnie Boyd (5 May 2008) | |
| . \ Doug Schaefer (5 May 2008) | |
| . . \ Aaron W. LaFramboise (5 May 2008) | |
| . . \ John Marriott (11 May 2008) | |
| . . . \ Earnie Boyd (11 May 2008) | |
| . . . . \ John Marriott (11 May 2008) | |
| . . . . . \ Earnie Boyd (11 May 2008) | |
| . . . . . . \ NightStrike (11 May 2008) | |
| . \ John Brown (5 May 2008) | |
| . . \ Aaron W. LaFramboise (5 May 2008) | |
| . \ JonY (6 May 2008) | |
| . . \ Bob Rossi (6 May 2008) | |
| . . . \ Greg Chicares (6 May 2008) | |
| . . . \ Aaron W. LaFramboise (6 May 2008) | |
| . . . . \ Bob Rossi (6 May 2008) | |
| . . . . . \ Tonal (6 May 2008) | |
| . . . . . . \ Bob Rossi (6 May 2008) | |
| . . . . . . . \ Mathias Fröhlich (6 May 2008) | |
| . . . . . . . . \ Bob Rossi (6 May 2008) | |
| . . . . . . . \ Earnie Boyd (6 May 2008) | |
| . . . . . . . . \ Aaron W. LaFramboise (6 May 2008) | |
| . . . . . . . . . \ Earnie Boyd (6 May 2008) | |
| . . . . . . . . . \ Danny Smith (7 May 2008) | |
| . . . . . . . . . . \ NightStrike (7 May 2008) | |
| . . . . . . . . . . . \ Danny Smith (7 May 2008) | |
| . . . . . . . . . . . . \ NightStrike (7 May 2008) | |
| . . . . . . . . . . . \ Kai Tietz (7 May 2008) | |
| . . . . . . . . . . \ Earnie Boyd (7 May 2008) | |
| . . . . . \ Aaron W. LaFramboise (6 May 2008) | |
| . . . \ Tonal (6 May 2008) | |
| . . . . \ Bob Rossi (6 May 2008) | |
| . . . . \ Aaron W. LaFramboise (6 May 2008) | |
| . . . . . \ Tonal (8 May 2008) | |
| . . . . . . \ Tonal (8 May 2008) | |
| . . . . . . \ Earnie Boyd (8 May 2008) | |
| . . . . . . . \ Tonal (8 May 2008) | |
| . . . . . . . . \ Aaron W. LaFramboise (8 May 2008) | |
| . . . . . . . . \ Earnie Boyd (8 May 2008) | |
| . . . . \ Tonal (6 May 2008) | |
| . \ Brian Dessent (6 May 2008) | |
| . \ Brian Dessent (6 May 2008) | |
| . . \ Aaron W. LaFramboise (6 May 2008) | |
| . . . \ Tonal (6 May 2008) | |
| . . . . \ Aaron W. LaFramboise (6 May 2008) | |
| . \ Brian Dessent (6 May 2008) | |
| . . \ Aaron W. LaFramboise (6 May 2008) | |
| . . \ Greg Chicares (6 May 2008) | |
| . \ StéphaneLarouche (7 May 2008) | |
| . . \ Aaron W. LaFramboise (8 May 2008) | |
| . \ ATS (7 May 2008) | |
| . . \ Aaron W. LaFramboise (8 May 2008) | |
| . . . \ Tonal (8 May 2008) | |
| . \ Ramiro Polla (8 May 2008) | |
| . . \ Aaron W. LaFramboise (8 May 2008) | |
| . \ ATS (8 May 2008) | |
| . . \ Charles Wilson (8 May 2008) | |
| . . . \ Tonal (8 May 2008) | |
| . . . . \ Aaron W. LaFramboise (8 May 2008) | |
| . \ Sisyphus (8 May 2008) | |
| . . \ Aaron W. LaFramboise (8 May 2008) | |
| . \ Danny Smith (8 May 2008) | |
| . . \ Aaron W. LaFramboise (8 May 2008) | |
| . \ StéphaneLarouche (10 May 2008) | |
| . . \ Aaron W. LaFramboise (10 May 2008) | |
| . \ Brian Dessent (10 May 2008) | |
| . \ StéphaneLarouche (10 May 2008) | |
| . \ Tonal (11 May 2008) | |
| . . \ Tonal (11 May 2008) | |
| . . . \ JonY (11 May 2008) | |
| . . . . \ Tonal (11 May 2008) | |
| . . \ Tonal (11 May 2008) | |
| Prev-20 | Home | Next-20 |
| Prev-Msg | Prev-Thread | Mingw-users | May-2008 | Next-Thread | Next-Msg |
| Subject: | Re: GCC 4.3.0 20080502 (alpha) Released - Please helpus test it! |
| Group: | Mingw-users |
| From: | ATS |
| Date: | 7 May 2008 |
> > 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
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
| Prev-Msg | Prev-Thread | Mingw-users | May-2008 | Next-Thread | Next-Msg |