emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MPS: Win64 testers?


From: Pip Cet
Subject: Re: MPS: Win64 testers?
Date: Thu, 25 Jul 2024 15:39:51 +0000

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]