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
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
