Re: MPS: Win64 testers?

[Eli Zaretskii]

> Date: Sat, 27 Jul 2024 10:42:12 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: emacs-devel@gnu.org
> 
> > If the "_setjmp_ex assumes 16-byte alignment of jmp_buf to store the
> > XMM registers" part is about what Wine does, then my question is where
> > did you see that "we allocate handlers with 8-byte alignment in MPS
> > builds"?
> 
> All our pools are aligned to IGC_ALIGN, which is GCALIGNMENT, which is 8 
> bytes on this system.
> [...]
> > > - force LISP_ALIGNMENT to be 8, not 16
> > 
> > 
> > Does this mean 'struct Lisp_*' structures are 16-byte aligned in the
> > 64-bit MinGW build? If not, what forces LISP_ALIGNMENT to be 16?
> 
> emacs_align_type contains struct thread_state, which contains a jmpbuf, which 
> is 16-byte aligned.

And that is specific to MS-Windows?  Don't Posix systems store XMM
registers in jmpbuf as well?

> > > - make sys_setjmp and sys_longjmp use a larger buffer and memmove() the 
> > > data in it so it's 16-byte aligned
> > 
> > Why would this be any different from a non-MPS build for 64-bit MinGW?
> 
> Because non-MPS allocates handlers with xmalloc(), which is 16-byte aligned, 
> and the jmpbuf in it is, too. I expect the change is required on MPS builds 
> on native Windows, too, though, because that also specifies 16-byte alignment 
> for jmpbuf, IIUC.

Maybe the way you made MPS compile with MinGW64 is incorrect, because
it ought to return the same alignment as malloc on the target
platform?  What is the value of MPS_PF_ALIGN you used for building
MPS?  Also, did the library pass the test suite?  I had some failures
until I set MPS_PF_ALIGN to the right value (8 for the 32-bit build).

> > > - disable the failure exit on close_stream failure in sysdep.c, and 
> > > silently ignore such errors
> > I guess you are using UCRT? These problems with UCRT are known, but
> > no one came up with an explanation for them yet. What happens if you
> > link against MSVCRT instead?
> 
> I'm using the msys2-docker-experimental image with MSYSTEM=MINGW64. I don't 
> know whether that means I'm using UCRT, sorry. If I use MSYSTEM=UCRT64, I get 
> many more and different problems...

There are no problems with close_stream when linking against MSVCRT,
AFAIK.  Problems such as what you report were only reported in UCRT
build.