On Friday 03 July 2026 01:00:15 Martin Storsjö wrote: > On Sun, 28 Jun 2026, Pali Rohár wrote: > > > Evgeny, you bring this issue for arm64 and I have prepared a fix which > > is in the attachment of the previous email. Could you please check and > > test it? I really need feeback from your configuration / setup of > > toolchain to know if it address your issue. Because I do not have it. > > > > Martin, if you have a time, could you do (code) review for first two > > changes which are for amd64 (which is rewriting / replacing the > > __mingw_init_ehandler implementation)? > > Those patches feel like super overkill. > > I don't think we should have code to construct SEH unwind code by hand here. > I really can't see why we should need to do that.
For example, it is needed for C signal handlers. > Why do we need to complicate every detail 10x to make our code even more > inflated and unmaintainable? Well, it was already there in the __mingw_init_ehandler function and which I have pointed out is broken. So I chose the direction to try to fix it and figure out how the whole picture is working. > We can't just try to add some random inline assembly snippets and calls to > __builtin_frame_address() and hope that the compiler generates a specific > form of prolog for the function based on that. If we ever try to do that, > we're doing something really wrong. (And the wrong thing can also just be > that you're trying to fix a case which we shouldn't try to fix.) In this case, I would propose to completely remove the __mingw_init_ehandler code. IMHO it does not make sense to have it in the current state when it is not working as expected. > I explicit do _not_ want those patches merged. > > > For builds with SEH disabled, I don't think anybody expects all of "make > check" to pass. (Heck, it was only about a year ago that we even made "make > check" work at all again.) A toolchain can be very well functioning for a > lot of practical usecases without having those details handled in the right > way. > > For builds with SEH disabled, just ifdef out whatever constructs don't > compile in that form. > > // Martin I understand your point about simplification. Sounds like better direction. We can put signal function (and other related) in header files into ifdef block too, those things which are not available without SEH would not be possible to use. This can simplify the code with the restrictions which toolchain have. And by completely removing the __mingw_init_ehandler, it can also decrease maintenance. The question is what else is broken without the SEH support on non-i386 platforms. _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
