On Mon, Apr 17, 2023 at 8:56 PM Martin Storsjö <[email protected]> wrote:
> On Mon, 17 Apr 2023, sisyphus wrote: > > > On Mon, Apr 17, 2023 at 1:02 AM Martin Storsjö <[email protected]> wrote: > [snip] > > 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. > > Well, the perl threads.xs header seems to try to fix things in two ways: > - Defining USE_NO_MINGW_SETJMP_TWO_ARGS, which affects what mingw-w64 > setjmp.h does (making setjmp expand to _setjmp() instead of _setjmp3()), > introduced in 2009 > - Manually undeffing setjmp and redefining it to _setjmp(), introduced in > 2006 (for all windows compilers except Borland, i.e. for MSVC too) Agreed. > The mingw-w64 commit that removed use of USE_NO_MINGW_SETJMP_TWO_ARGS > would have affected the former, but I don't see why it would affect the > latter; if the latter works as intended there would be no need for > USE_NO_MINGW_SETJMP_TWO_ARGS in the first place. Yes - in our 32-bit builds the condition: # if defined(USE_NO_MINGW_SETJMP_TWO_ARGS) || (!defined(__BORLANDC__) && !defined(__MINGW64__)) will be true even if USE_NO_MINGW_SETJMP_TWO_ARGS is NOT defined. In that sense, there's no need to define USE_NO_MINGW_SETJMP_TWO_ARGS. But, wrt the 12.2.0 setjmp.h, USE_NO_MINGW_SETJMP_TWO_ARGS still needs to be defined in order to avoid entering the block of code that begins with: #if !defined(USE_NO_MINGW_SETJMP_TWO_ARGS) The 13.0.1 setjmp.h has no such block ... though I haven't yet properly assessed the impact of that absence. (TODO) Apparently, it's quite ok for MSVC to enter that block. I regularly build threaded 32-bit (and 64-bit) perls using VS-2022,and this is not an issue. > Do the headers EXTERN.h, perl.h and XSUB.h include the system setjmp.h? I > guess they do, since otherwise there's little point in doing the undef of > setjmp after including them. Yes, that's right. > Do those headers end up calling setjmp() > themselves, so that the redefine in threads.xs comes too late? > > I don't think so. It's perl.h that includes setjmp.h (but doesn't explicitly call anything else that contains a match for "setjmp"). XSUB.h undefs setjmp, and then defines setjmp to PerlProc_setjmp, but takes no other action (involving either 'setjmp' or 'PerlProc_setjmp'). In threads.xs, setjmp is immediately then undeffed yet again. > In that case it's understandable, but wouldn't the same issue (using the > system's default setjmp instead of the one Perl tries to redefine it to) > hit other compilers like MSVC too? > > So in short, we'd need to know which code, where, ends up calling _setjmp3 > instead of _setjmp, despite threads.xs's attempts to redefine it. > > >> On a lower level, since commit > >> 82347ded0d43a80de68ba6a35a209717bded5f28a 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. > > I'm not exactly sure what's going on here, but I'm quite sure that > reverting that commit would fix things again. Didn't you say that picking > the setjmp.h header from your gcc 12 build into your gcc 13 build made > things work again? I believe that's fundamentally what reverting that > commit would do. Best thing would be for me to actually test what you have in mind. What does this reverted setjmp.h exactly look like ? (A patch that I can apply would suffice.) Could I then simply test this reverted header by inserting it into my current gcc-13.0.1 installation, as a replacement for the setjmp.h originally provided ? Or does this reversion require that gcc-13.0.1 be rebuilt ? (I'm not set up to build gcc from source, and would prefer not to.) The 12.2.0 version of setjmp.h caters for a setjmp() function that takes a single jmp_buf argument. It looks to me that the 13.0.1 version of setjmp.h does not provide that option. > 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.) > > FWIW, I'm curious about what that msvcrt-specific code is; I'd be happy to > help with pointers if you want to take a dive into that at some point. > I was thinking mainly of the various '.c' and '.h' files in the win32 directory of the source but I might have been barking up the wrong tree. See the (fairly brief) discussion initiated by Biswa in https://github.com/Perl/perl5/issues/18772. (TBH,that discussion is a bit "over my head" .) > > AFAIK, 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 ? > Since that's the default of mingw-w64 since 2009 on i386, I guess that'd > be a good direction, to reduce the amount of brittle hacks. I would > presume that doing that would reveal what the original reason for > redefining setjmp was. > Not sure that I'm the right person for that job ... I'd personally prefer to be able to revert to using the 12.2.0 version (or equivalent) of setjmp.h, even if that means I'm just "kicking the can down the road" ;-) But I could work on refactoring it as time permits ... and drag in some better qualified perl folk when needed. My apologies if you find reading this to be as exhausting as it was for me to write it. I did not set out to drag any mingw-w64 developers into this level of discussion ;-) ASIDE: With gcc-12.2.0 and earlier, some configurations of our threaded builds of 32-bit perl failed a number of threads-related tests in the test-suite. (However, they were basically functional.) Having now built threaded 32-bit perls using gcc-13.0.1 (courtesy of 12,2,0 setjmp.h), I'm pleasantly surprised to find that all tests are now passing for all configurations !! Perhaps it's gcc-13.0.1 itself that's provided that improvement, but could it alternatively be the enablement of MCF threads in the gcc-13.0.1 builds that has somehow "fixed" those previous (undiagnosed) issues ? Cheers, Rob _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
