[Attn: gcc maintainers] Re: unhandled C++ exceptions not propagating

Ken Brown kbrown@cornell.edu
Mon Aug 17 20:40:07 GMT 2020


On 8/17/2020 3:06 PM, Ken Brown via Cygwin wrote:
> On 8/17/2020 2:13 PM, Corinna Vinschen wrote:
>> On Aug 17 13:36, Ken Brown via Cygwin wrote:
>>> On 8/16/2020 6:38 PM, Ken Brown via Cygwin wrote:
>>>> One further comment, and then I'll shut up
>>>
>>> I lied.
>>
>> ...which is ok.
>>
>>>> and leave it to people who know what they're talking about: In the
>>>> 64-bit case, the function _Unwind_RaiseException in libgcc/unwind-seh.c
>>>> gets called, and it calls the Win32 function RaiseException as follows:
>>>>
>>>>     RaiseException (STATUS_GCC_THROW, 0, 1, (ULONG_PTR *)&exc);
>>>>
>>>> Then the following comment appears:
>>>>
>>>>     /* The exception handler installed in crt0 will continue any GCC
>>>>        exception that reaches there (and isn't marked non-continuable).
>>>>        Returning allows the C++ runtime to call std::terminate.  */
>>>>
>>>> Apparently this doesn't actually happen.
>>>
>>> I'm beginning to think this is a bug in the Cygwin build of gcc.  The file
>>> unwind-seh.c is compiled on 64-bit Cygwin because __SEH__ is defined.  But
>>> it makes assumptions, such as those in the comment quoted above, that are
>>> not valid on Cygwin.
>>>
>>> In fact, if you look at the main exception handler on Cygwin
>>> (exceptions.cc:626), it is clear that the exception code STATUS_GCC_THROW
>>> does not lead to continuation.  It falls under the default case:
>>>
>>>      default:
>>>        /* If we don't recognize the exception, we have to assume that
>>>      we are doing structured exception handling, and we let
>>>      something else handle it.  */
>>>        return ExceptionContinueSearch;
>>>
>>> [STATUS_GCC_THROW is 0x20474343, which shows up in the gdb output above as
>>> an unknown target exception.]
>>>
>>> So it seems to me that either Cygwin's exception handler has to learn to
>>> handle the exception codes defined in unwind-seh.c, or else gcc should be
>>> built with __SEH__ undefined.
>>>
>>> JonY, Achim, Corinna, am I missing something?
>>
>> This stuff isn't really my strong point.  IIUC the above comment correctly,
>> we might get away with adding another case to the exception handler switch:
>>
>>    #define STATUS_GCC_THROW 0x20474343
>>    case STATUS_GCC_THROW:
>>      return ExceptionContinueExecution;
>>
>> Did you try that, by any chance?
> 
> No, I didn't.  It might well solve the immediate problem of this bug report. But 
> then there are two other exception codes that occur in unwind-seh.c that we 
> would also have to deal with: STATUS_GCC_UNWIND    and STATUS_GCC_FORCED.  
> Someone would have to look at their uses and figure out what, if anything, 
> Cygwin should do with them.

This isn't an issue after all.  The comment I quoted above refers to all GCC 
exceptions, not just STATUS_GCC_THROW.  I'll submit a patch after testing.

Ken


More information about the Cygwin mailing list