From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: MPS: Win64 testers? Date: Sat, 27 Jul 2024 15:14:01 +0300 Message-ID: <86ttgb1186.fsf@gnu.org> References: <86le1q54bw.fsf@gnu.org> <86zfq31cvc.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28269"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jul 27 14:15:09 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sXgKK-0007BJ-AE for ged-emacs-devel@m.gmane-mx.org; Sat, 27 Jul 2024 14:15:08 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sXgJe-0003zj-6X; Sat, 27 Jul 2024 08:14:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sXgJa-0003zA-3b for emacs-devel@gnu.org; Sat, 27 Jul 2024 08:14:22 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sXgJY-0008W0-6w; Sat, 27 Jul 2024 08:14:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Vpr0GQuJF5VzqhVS9p0IvVHLWEnjGbM8OKqy0LJAYHo=; b=muKWQODpXW2G Af8FgbklrFFkA317h0ZftNa9hlK1FZ/BmfcEJvvtF7Hv36RFGh1tdbwAJcNNWr1TJMIQm0xc5km/n pd80dT2J/euRAG3ocX8SgsFuPlNOfClC2K+WZo/+AZQasSeXd9Ywl7lCEknNowkmGAkgjKyBdSq7Y aK1XNMaNsy5QaiBWQeTY8evFO6KjdOTSPRmtuIZPvMeULMPsmLP3Z0CsydKo0p3YQ1Qcq/a0znAvY tZKE1a8ycozfE36UKAXUqG2vzMDndLGutMnKWunHbGVqLYdwc36LcNEB5c89jsYk+UUBAbjulcP1P yX2HRbnbHbmrsnPKQBjzUw==; In-Reply-To: (message from Pip Cet on Sat, 27 Jul 2024 10:42:12 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:322125 Archived-At: > Date: Sat, 27 Jul 2024 10:42:12 +0000 > From: Pip Cet > 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.