On Wednesday 17 June 2026 10:47:09 LIU Hao wrote: > 在 2026-6-17 01:03, Pali Rohár 写道: > > 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) > > You mentioned that it should be necessary to unregister the table - yes, you > may call `__cxa_atexit()`, or define a TLS callback to unload it upon > `DLL_PROCESS_DETACH`.
Yes. In the change which I attached to that email I already chose to use DLL_PROCESS_DETACH for unregistering the table. > > > 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 > What can happen if stack unwind goes across a frame that was not compiled > with unwind information? The DWARF2 unwinder terminates the process if it > can't find unwind information for a frame; and even if it could have > continued like SJLJ does, MSVC frames may have their own SE handlers, so > unwinding over such frames may leave a dangling pointer in FS:[0]. Mixing of code with different unwind schemes obviously needs cooperation so at the DLL crossing needs required synchronization of handling such things. That is probably harder but important is that this is a problem of application which is going to do that mixing. One simple solution is to not use any unwindning in application at all. E.g. plain C with no long jumps and no signal handlers mostly matches this. _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
