On Mon, Apr 17, 2023 at 1:02 AM Martin Storsjö <[email protected]> wrote:
> mingw-w64 never defined USE_NO_MINGW_SETJMP_TWO_ARGS. Do the perl sources > define it? > Yes - and for quite a long time. (But only for 32-bit builds of course.) https://github.com/Perl/perl5/blob/blead/dist/threads/threads.xs begins with ########################### #define PERL_NO_GET_CONTEXT /* Workaround for mingw 32-bit compiler by mingw-w64.sf.net - has to come before any #include. * It also defines USE_NO_MINGW_SETJMP_TWO_ARGS for the mingw.org 32-bit compilers ... but * that's ok as that compiler makes no use of that symbol anyway */ #if defined(WIN32) && defined(__MINGW32__) && !defined(__MINGW64__) # define USE_NO_MINGW_SETJMP_TWO_ARGS 1 #endif #include "EXTERN.h" #include "perl.h" #include "XSUB.h" /* Workaround for XSUB.h bug under WIN32 */ #ifdef WIN32 # undef setjmp # if defined(USE_NO_MINGW_SETJMP_TWO_ARGS) || (!defined(__BORLANDC__) && !defined(__MINGW64__)) # define setjmp(x) _setjmp(x) # endif # if defined(__MINGW64__) # include <intrin.h> # define setjmp(x) _setjmpex((x), mingw_getsp()) # endif #endif .... ########################## As you can see, the aim is, for 32-bit builds only, to: # define setjmp(x) _setjmp(x) and, while that works fine with the 12.2.0 setjmp.h, it does not work with the 13.0.1 setjmp.h. On a lower level, since commit 82347ded0d43a80de68ba 6a35a209717bded5f28a in 2009, mingw-w64's setjmp.h has been using _setjmp3 for i386, while setting > the USE_NO_MINGW_SETJMP_TWO_ARGS define makes it revert to using _setjmp. > > We weren't aware of any issues with using _setjmp3 (and if there are, > maybe we should revisit that change from 2909?) - ideally user code > shouldn't need to know or care about this - the defaults are supposed to > work. > Yes - that might be pertinent to the issue But the current threads.xs source just undefs that setjmp.h definition and then defines setjmp() back to using _setjmp(). So I don't see that reverting 82347ded0d43a80de68b6a35a209717bded5f28a will necessarily help. In case it's relevant, we use only msvcrt compilers to build perl. (Perl source currently won't build with ucrt - because of the abundance of msvcrt-specific code in certain places, I expect.) FAIK, it's quite possible that the perl source could be refactored to use _setjmp3(). Should we (ie perl maintainers) be trying to do just that ? Thanks for the explanation, Martin. Cheers, Rob _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
