On Tuesday 16 June 2026 12:25:13 LIU Hao wrote: > 在 2026-6-15 04:26, Pali Rohár 写道: > > So based on this I'm proposing the following changes: > > - completely remove __mingw_init_ehandler and replace by new code > > This change should be correct. > > > > - register unwind code for standard prologue (push %rbp; mov %rsp %rbp) > > for all executable code in the module (for both exe and dll builds) > > But this isn't correct unwind code; it leaves non-volatile registers (RBX, > R[SD]I, R1[2345], and XMM6-15) clobbered, and it has no information of stack > allocation.
Yes, it is not "the correct one" unwind code. Its purpose is just for propagating SEH exceptions which occurs in non-SEH-compiled code. So the purpose is very limited. mingw-w64 SEH exception handler does not require all that information and if I understand the logic and code correctly, that mingw-w64 SEH exception handler should work fine. Without compiler SEH support we even cannot provide "the correct one" unwind code as we do not know how registers are used, where the original values are stored and how the stack is being used. So the only thing what can from my perspective is to provide logic how to find previous stack frame which would allow to call registered mingw-w64 SEH handler. > > > Please let me know what do you think about it. If I should continue on > > this direction and create final version of this change. Or this is wrong > > direction and something different should be done. > I think that any builds that have SEH disabled are unsupported -- not just > because of exceptions, longjmp also won't work reliably. Martin had different opinion, that it should be supported. So I tried to present something which could work for at least some specific cases. Something which could work for use cases which Evgeny has. longjmp is another topic, but it could be also fixed to not use SEH. Even CRT DLLs expose a way how to use longjmp without SEH and without stack unwinding. I think that at this stage first we should decide if: 1. current __mingw_init_ehandler should stay in mingw-w64 source code or if it should be completely deleted (In previous email I wrote reasons why I suggest to delete it) 2. mingw-w64 should support non-SEH builds for non-i386 platforms (i386 SEH is different than all others; gcc has no i386 SEH support and more important stack traverse works fine also for non-SEH code) 3. and if mingw-w64 should support non-SEH builds, what exactly it should mean how (what kind of support) and how to achieve it _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
