在 2026-6-3 03:03, Pali Rohár 写道:
I'm not fully sure about this as I information which I found on archived MS web and also in other resources which comes prior introduction of amd64 shows that handler is (or was?) cdecl.
In Microsoft SDK, `EXCEPTION_ROUTINE` is declared `NTAPI` which is `__stdcall`. There was no such type in Windows 2003 SDK.
Raymond Chen uses `__stdcall` in his blog: https://devblogs.microsoft.com/oldnewthing/20220418-00/?p=106489
Anyway, I mentioned it also in the commit message, even mingw-w64 header files have different definitions of that handler (some are cdecl, some are stdcall and some are without any keyword). So this is something which would be aligned to the one calling convention.
People who use the type shall have known the difference; it's the same if they use MSVC.
If the handler can be declared in either calling convention then it should mean that caller of that handler needs to preserve %esp register (by copying it into %ebp addressed stack or into %ebx, %esi or %edi reg) before pushing arguments on stack and restore it after handler returns. That is because the caller of handler cannot know calling convention and whether handler pops the stack or not. At least this is my theory how it could work if handler can be really either cdecl or stdcall. It is somewhere documented?
No, I suspect? On x86-32, a handler is not invoked directly, but through a wrapper in assembly, which Wine also has: https://gitlab.winehq.org/wine/wine/-/blob/83f7493618de3c0f5a8461720a7aa1f1a7db2f37/dlls/ntdll/signal_i386.c#L671
Ok, this is really bad. Is C even allowing to run signal handler in different thread than the which one triggered it?
For synchronously-generated signals, no. (but this is POSIX definition.)
sigsetjmp/siglongjmp functions are needed by that SIGFPE test. I see that there is a proposal to rename those functions with mingw prefix. Another possible option could be to not introduce these functions at all into mingwex library, but instead put implementation of them as static non-exported functions into the SIGFPE test itself. What do you prefer more? If there is such issue with SIGINT, I'm not really sure if it is a good idea to have such function (even prefixed by __mingw) exported for all applications. So I slightly prefer to have them in the test code.
Maybe you can just use `longjmp`. The effect is unspecified, but it's better than not having a test all.
This change is needed just for one or two intermediate commits. Is the extending the description for that intermediate commit needed?
OK. -- 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
