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

[Ken Brown]

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.

I'd be willing to take a crack at this if no one more knowledgeable steps 
forward.  But keep in mind that I've never looked at the gcc code or Cygwin's 
exception handler until today, so I'm not necessarily the best person to do this.

Ken