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 19:10:50 +0300 Message-ID: <86le1m24tx.fsf@gnu.org> References: <86le1q54bw.fsf@gnu.org> <86zfq31cvc.fsf@gnu.org> <86ttgb1186.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9917"; 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 18:11:31 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 1sXk14-0002QL-Ch for ged-emacs-devel@m.gmane-mx.org; Sat, 27 Jul 2024 18:11:30 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sXk0Y-0001A2-Jb; Sat, 27 Jul 2024 12:10:58 -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 1sXk0W-00019i-06 for emacs-devel@gnu.org; Sat, 27 Jul 2024 12:10:56 -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 1sXk0V-0000CB-Co; Sat, 27 Jul 2024 12:10:55 -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=p6nZBtCpAaG5fhZXvoJotqy2nPWkLcIKLQ0OBq5sDOw=; b=sgWscETzaGUA 91lhGMfx7N1JWznSTEoPKSqnKMYdctUfPN8iDE0XMcrg71Kj6WPY1vnHUIe+xpk4imk2no4PTRy7b 4N2/KaOGj91XZ5vVqsSC5B7KC/I34YjILKlVkw1VAOZMTP2sVd/2aluA9O/W6KNJAPHdStMnJ2Za/ PqCc+kw4K8vcfcN0xKXZIJWQ6pJxCI41n7UPUXggaQ6YFqT/c0scTV5zLLu7GVbN74XEm9kf9dNlY ChboXsshnVsa0pYIItlCLjU6T4ylsjM5+xcDA3F1mrgaCad7XssDtn7vxaXCHE8zLKxidp5lOZOTr wBQ3qEgjZefxtkaXCRw+/A==; In-Reply-To: (message from Pip Cet on Sat, 27 Jul 2024 15:49:59 +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:322133 Archived-At: > Date: Sat, 27 Jul 2024 15:49:59 +0000 > From: Pip Cet > Cc: emacs-devel@gnu.org > > > > > > - 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? > > The SYSV ABI declares all XMM registers to be caller-saved, which means on such systems we don't store the XMM registers in a jmpbuf. > > > > > > - 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, > > Very possible. > > > because > > it ought to return the same alignment as malloc on the target > > platform? > > I'm not sure that's correct, I think it assumes you pass the right value for MPS_KEY_FMT_ALIGN. Currently the code passes 8, which is necessary to keep conses at a mere 24 bytes. > > > 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). > > The patch you sent has it at 4, though? Yes, because some tests failed with 8. But note that the MSVC 64-bit build uses 16. > > > > > - 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. > > I think the problem is init_ntproc in w32.c, which closes stdin, stdout, stderr, then calls _fdopen and assumes the result will live in stdin, stdout, stderr again. If I disable that code the backtick problem goes away: > > fclose (stdin); > fclose (stdout); > fclose (stderr); > > if (stdin_save != INVALID_HANDLE_VALUE) > _open_osfhandle ((intptr_t) stdin_save, O_TEXT); > else > _open ("nul", O_TEXT | O_NOINHERIT | O_RDONLY); > _fdopen (0, "r"); Why do you think it's a problem? And why do you think the assumption of fdopen is incorrect? It is confirmed by the source code of MSVCRT. > I believe that last line should, possibly, on some systems, be > > stdin = _fdopen (0, "r"); > > but I'm not sure the variable (or macro) stdin is an lvalue. That's probably why close_stream(stdout) and close_stream(stderr) fail, too: the streams they refer to are already closed, and the new streams we should be using instead were discarded. But this never fails in MinGW builds on Windows.