On Friday 12 June 2026 10:22:15 Martin Storsjö wrote: > On Fri, 12 Jun 2026, LIU Hao wrote: > > > 在 2026-6-12 01:57, Evgeny Karpov 写道: > > > On 11 Jun 2026, Pali R. wrote: > > > > Could you enable the ifdef branch which calls __mingw_init_ehandler? > > > > It would be needed to enable it also in crt_handler.c file. > > > > > > It should be possible, however it should be sufficient to add this change > > > as a temporary workaround. > > > > > > + #elif defined(__aarch64__) && !defined(__clang__) > > > + /* __SEH__ is not implemented yet for aarch64-w64-mingw32 GCC > > > target. */ > > I understand that SEH is not currently implemented in GNU toolchains for > > aarch64-w64-mingw32. > > > > Since the proposed change is only 'a temporary workaround', I suggest > > you put it in your workflows. If this change was committed to mingw-w64, > > then once you have a fully operational toolchain in the future, it would > > be mingw-w64 that would seem broken. > > FWIW, I think it could be entirely reasonable to have cases with "#if > defined(__SEH__)" around such cases, where applicable, to allow building > without SEH on such architectures. > > Even with llvm-mingw, the aarch64 target didn't use SEH, but DWARF unwind > info, for the first couple years, until LLVM (and libunwind) supported SEH > on aarch64. And for 32 bit ARM, it took yet another couple years before that > could be switched to SEH (as late as in 2022). > > It's easy to tweak a from-scratch build of llvm-mingw to use these different > unwind info formats, by adding e.g. a "-fdwarf-exceptions" in > "wrappers/aarch64-w64-windows-gnu.cfg" - just like you can configure a build > of GCC to use either SJLJ, DWARF or SEH. (SEH is obviously the default on > x86_64 these days, but I do remember seeing e.g. Qt being built with a SJLJ > x86_64 toolchain for quite long after SEH being generally usable - same with > e.g. distro shipped compilers.) > > For upstream mingw-w64, we probably can't commit to continuously testing and > maintaining that all these build configurations work (that'd be a pretty bad > extra combinatorial explosion), but I think it'd be fair to accept patches > to fix it, if someone wants to contribute it.
I will look at it. Just give me some time to understand how that __mingw_init_ehandler needs to differ between architectures. > One probably can't expect all the corner cases around unwind etc to work > with the same quality of implementation as with SEH now, but I would want > such a toolchain to "generally work" at least. > > // Martin _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
