Re: MPS: Win64 testers?

[Pip Cet <pipcet@protonmail.com>]

On Thursday, July 25th, 2024 at 07:16, Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Wed, 24 Jul 2024 15:45:18 +0000
> 
> > From: Pip Cet pipcet@protonmail.com
> >
> > Is anyone building the scratch/igc branch for/on win64 systems? I'm trying to do that on wine/msys2/mingw64 (not an actual Windows installation), and there are a number of issues that need to be fixed, and I'm wondering whether I'm the first person to run into them. Quite possibly, they're specific to wine.
> 
> I think you are indeed the first one. I use 32-bit MinGW, and for
> that I have a working build of MPS (and can share the diffs if someone
> wants them), but a 64-bit MinGW build of MPS will need other changes,
> at least in some cases.

It'd be great if you could share the diffs, so I could see where I've gone wrong! I've got the 64-bit build with mps to start by now, but haven't really tested it for stability much. It survives a few garbage collection cycles, at least.

As a general question, would there be interest in CI for such systems? I'm setting up something locally, but I've been trying to be careful so that the Dockerfiles I'm using should work on x86_64 GNU/Linux machines generally.

> > - _setjmp_ex assumes 16-byte alignment of jmp_buf to store the XMM registers, but we allocate handlers with 8-byte alignment in MPS builds.
> 
> Where and how do you see that?

I'm not quite sure what you're asking. I saw this trying to run things in wine in a docker image on an x86_64 GNU/Linux machine, ran it in gdb.exe, found the instruction causing the segfault, and fixed things so it wouldn't.

https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/winecrt0/setjmp.c#L123 is the instruction that segfaulted here. I'm not sure whether that's what you were asking.

The jump buffer is declared with 16-byte alignment here: https://gitlab.winehq.org/wine/wine/-/blob/master/include/msvcrt/setjmp.h#L50

A side effect of this is that LISP_ALIGNMENT is 16, which breaks MPS because vectorlike_nbytes rounds up to a multiple of LISP_ALIGNMENT, not just GCALIGNMENT.

Looking over my diff, here's what I had to fix to get things to the current stage on msys and msys2 (using MSYSTEM=MINGW64).

- disable the sanity check in the Makefile, because backticks/pipes don't work properly
- make WINDRES include the --use-temp-file flag, for the same reason
- wrap the add-name-to-file calls in loadup.el in with-demoted-errors (link problems?)
- force LISP_ALIGNMENT to be 8, not 16
- change my local generation size settings to be much more conservative for the msys build. I think scratch/igc is fine, though.
- make sys_setjmp and sys_longjmp use a larger buffer and memmove() the data in it so it's 16-byte aligned
- disable the failure exit on close_stream failure in sysdep.c, and silently ignore such errors
- trace the extra 'ztrillion' bignum in timefns.c
- for the msys build, run autogen.sh outside of wine, since there are virtual memory issues inflooping the process otherwise

I must confess I know little about the UCRT64 default MSYSTEM value. Maybe it doesn't have the same problems.

If anyone wants to study or reuse any of my efforts, let me know and I'll provide a link to a public repository that can be used. Note that my Wine build environment, as far as I know, uses only free software, so it's in the "technically free OS" category. (The Android build uses the SDK, which claims to be decidedly non-free but makes an exception for those components which are indeed free; that means it's possible to build Android APKs without paying for it, using non-free software, and run them on technically free Android versions if you can find those. AFAIK, the macOS build requires non-free and expensive software both to compile and to run the executable?)

Pip