在 2025-12-25 23:27, Pali Rohár 写道:
Anyway, I found out that the crtdll/msvcrt/UCRT library provides its own Windows SEH handler function and works as a dispatcher to other user filer and error recovery functions.For i386 versions that Windows SEH handler which works like CRT dispatcher function is called "_except_handler<num>" (where num depends on used msvcrt version, but num=2 is supported in all libs) and for other non-i386 platforms it is called "__C_specific_handler".
On i386 the exception handler is linked statically in binaries.And it's really only a handler -- every function has at most one handler (also true on non-i386). The scopes of try..catch statements and non-trivial objects are encoded in its handler-specific data. When an exception happens, the handler scans its handler-specific data for matching scopes, and invoke filters.
The pseudo code of `__C_specific_handler` can be found on https://www.osronline.com/article.cfm%5Earticle=469.htm. This explains why a NOP instruction is required after `.l_end`. If it wasn't there, and the instruction preceding `.l_end` was a CALL, then in the target function, the return address would equal `.l_end` and would be outside the scope of the filter.
And the GNU handler and MS handler don't work the same way: The GNU handler, `__gxx_personality_seh0`, handles (overtakes) the exception, tidies the stack of the current function, then calls `_Unwind_Resume()` to resume unwinding. The Microsoft handler, `__CxxFrameHandler4`, doesn't handle exceptions; instead, destructors of local objects are encoded in handler-specific data directly. The difference is illustrated by https://gcc.godbolt.org/z/4bTvP3bv9
I think that we do not need to use CRT dispatcher SEH handler __C_specific_handler as for all uses in mingw-w64 we define just one filter and recovery callback. So we can directly use our handler (__mingw_seh_error_handler).
Right, this isn't necessary, because there's only ever one scope, and most functions don't throw exceptions anyway.
What do you think by replacing the __C_specific_handler+_gnu_exception_handler usage by the __mingw_seh_error_handler in crtexe.c mainCRTStartup? _gnu_exception_handler is registered as a filter callback, not as a recovery callback and it never returns EXCEPTION_EXECUTE_HANDLER. Hence the recovery callback (defined as .l_end) is never executed. If we remove usage of UnhandledExceptionFilter and for i386 builds we register the __mingw_seh_error_handler then we do not need _gnu_exception_handler at all. Also for UWP builds we have just stub / nonworking __C_specific_handler implementation which would not be needed too.
This makes sense. -- Best regards, LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
