From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: 32-bit MinGW build with JIT Date: Thu, 16 Aug 2018 17:09:15 +0300 Message-ID: <838t56iet0.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1534428562 9171 195.159.176.226 (16 Aug 2018 14:09:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 16 Aug 2018 14:09:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 16 16:09:18 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fqIxf-0002Fw-Mo for ged-emacs-devel@m.gmane.org; Thu, 16 Aug 2018 16:09:15 +0200 Original-Received: from localhost ([::1]:55878 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fqIzm-0000Qz-5K for ged-emacs-devel@m.gmane.org; Thu, 16 Aug 2018 10:11:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40852) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fqIxy-00088g-Ka for emacs-devel@gnu.org; Thu, 16 Aug 2018 10:09:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fqIxw-0008WR-JL for emacs-devel@gnu.org; Thu, 16 Aug 2018 10:09:34 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42131) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fqIxr-0008RP-IC; Thu, 16 Aug 2018 10:09:29 -0400 Original-Received: from [176.228.60.248] (port=1519 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fqIxr-00014K-17; Thu, 16 Aug 2018 10:09:27 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:228592 Archived-At: I tried to build the JIT branch with 32-bit MinGW tools. Since Tom said wide ints are not yet supported, I didn't configure with that option. The build failed half way through bootstrap. Specifically, bootstrap-emacs crashes the first time it attempts to JIT-compile a byte-compiled function, and then invoke the resulting JIT. The crash is in this snippet from eval.c: #ifdef HAVE_LIBJIT if (initialized) { struct Lisp_Vector *vec = XVECTOR (fun); if (vec->contents[COMPILED_JIT_CODE] == NULL) emacs_jit_compile (fun); if (vec->contents[COMPILED_JIT_CODE] != NULL) return funcall_subr (fun, (struct subr_function *) vec->contents[COMPILED_JIT_CODE], nargs, arg_vector); } #endif /* HAVE_LIBJIT */ funcall_subr calls the JIT function, which attempts to call Ffuncall, and the latter segfaults because its arguments are not valid Lisp objects. I'm not yet sure what causes this, but since I presume that the branch was successfully built on a 64-bit host, I suspect some snafu with pointers that are narrower than 64-bit integers. I couldn't yet spot any code that would be suspect, although some portions of the code work differently on 64-bit and 32-bit hosts, for example: if (sizeof (ptrdiff_t) == 8) ptrdiff_t_type = jit_type_ulong; else { eassert (sizeof (ptrdiff_t) == 4); ptrdiff_t_type = jit_type_uint; } (This is btw wrong, I think, in a 32-bit build --with-wide-int.) Also, I'm not sure why we are making a "long constant" (i.e., a 64-bit data type) here: mandatory_val = jit_value_create_long_constant (func, ptrdiff_t_type, mandatory); Why shouldn't this be of the same type as ptrdiff_t_type? Anyway, what I wanted to tell is that as of now, it is very hard to debug these problems. All the libjit types are "incomplete" as far as GDB is concerned, there are no facilities to display libjit types and values in human-readable form, C-level backtraces show ?? when a JIT compiled function is called, etc. I didn't yet succeed in establishing whether the invalid Lisp arguments for Ffuncall are already invalid when we compile the function, or get corrupted as part of compilation. I think we need to upgrade our debugging facilities, including adding commands to .gdbinit, as part of working on this branch. Tom, if you didn't try to build on a 32-bit host, could you please try that, so I could decide if what I report is specific to a 32-bit build or to MS-Windows? Thanks.