From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] [WIP] Port feature/native-comp to Windows. Date: Sun, 10 May 2020 16:02:11 -0300 Message-ID: References: <5eb5b953.1c69fb81.a67ce.a764@mx.google.com> <83lfm1hc91.fsf@gnu.org> <83wo5lds87.fsf@gnu.org> <83lflzd8es.fsf@gnu.org> <83ftc7d4zu.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="107108"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, Andrea Corallo To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 10 21:03:04 2020 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 1jXrE7-000Rk3-SB for ged-emacs-devel@m.gmane-mx.org; Sun, 10 May 2020 21:03:04 +0200 Original-Received: from localhost ([::1]:41680 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXrE6-0001tu-If for ged-emacs-devel@m.gmane-mx.org; Sun, 10 May 2020 15:03:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47706) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXrDX-0001TT-95 for emacs-devel@gnu.org; Sun, 10 May 2020 15:02:27 -0400 Original-Received: from mail-ot1-x336.google.com ([2607:f8b0:4864:20::336]:41359) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jXrDV-0007W2-Tk; Sun, 10 May 2020 15:02:26 -0400 Original-Received: by mail-ot1-x336.google.com with SMTP id c3so5796046otp.8; Sun, 10 May 2020 12:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=nLJ0MBlpKI6ilFrOtpUbHJp8OnoVMqjNyQzzwZ6Gkn8=; b=XeY0lg3HvXOPt6xfpejeV34E0Bnk9mqOsHSRDeal2IbGfQxHfydZoyWPxVeOGzhLuP 7JvuvaQIf01eAvem3RkIBcKVcrA3BjeR6sFdzHrwvNIVr6LE+v6d/Sx2PTBE/lciSK3R Y9EjFwFAGtYtNLwyWXK+CN8HfEml7znFoRPNcP5zJZ2OgdcxsZptgZc+tBhUfn0q7akq a5vFeCFBYcqXZ9Mexc90wJDuwIZaSpLt4F8Jkh0kpMtyWetwChvb27Ei7XRloNSp7RwH doQoHZUsJ/VIcvz9CB3kVDckR7Uj80nCh9O5thUUK8c3bh/m4wKchTNJFZ4R59Xqe8XZ VTwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=nLJ0MBlpKI6ilFrOtpUbHJp8OnoVMqjNyQzzwZ6Gkn8=; b=OZsoDr/qS/v5V+URdh/CscWhHUrIYGunvuvLcQv1yH5uTBcI7aFlwG3zF35YqzdtUI 0zfmaBBcK8ewWFuBVVCUDGvTzAoLx4eKSywl1S2WCrVNMGjmSc+TqrMWAw5wFFgyqIjp 69z7yyLIoS7awq07YIYOWnTwQeXX8vsdVs9uiYwAWJmkK4aDLFNzj3HzQPEsbSvLzgsj pEiN3boDk5PFtroJ/OiTq5DwLjnx+QVEcChCzZjxIW6i9YY9yuKo2hZdlkGp5KKqlxXD 2TABQiGutGqiufPoNJ7I/8+4N+En41yQsle4PBnT7dcregNSgXWOACVG7mEC5UnD/U/D z39Q== X-Gm-Message-State: AGi0Pub44sWyJ5jF1An0SLDvwkm8yX8osV2NaB13xOPJYqijwT/gbpb9 kfOkrq3cBaFWDMPmo+EdxrMfNptUllgBa6lu0/eBpz+CGmBCEw== X-Google-Smtp-Source: APiQypJcwMWmEIGWohN8xCWFvYGVa0sMY+brrX8slLKQwsIcyAY7QYpBiBDOr4VEBibQNplUCVb80+uHDRRB/K2HVcI= X-Received: by 2002:a9d:3988:: with SMTP id y8mr9513259otb.352.1589137343823; Sun, 10 May 2020 12:02:23 -0700 (PDT) In-Reply-To: <83ftc7d4zu.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::336; envelope-from=nicolasbertolo@gmail.com; helo=mail-ot1-x336.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:249698 Archived-At: > This is known in advance. We already have that knowledge in Emacs, > see HAVE__SETJMP and HAVE_SIGSETJMP used in lisp.h. > I don't yet understand why we need the _name_ of the setjmp function. > How will this name be used? I think it is a good idea to show how the information is used: This is the function that generates a function call to `setjmp`. static gcc_jit_rvalue * emit_setjmp (gcc_jit_rvalue *buf) { #ifndef _WIN32 gcc_jit_rvalue *args[] =3D {buf}; return emit_call (intern_c_string (STR (SETJMP_NAME)), comp.int_type, 1, = args, false); #else /* _setjmp (buf, __builtin_frame_address (0)) */ gcc_jit_rvalue *args[2]; args[0] =3D gcc_jit_context_new_rvalue_from_int (comp.ctxt, comp.unsigned_type, 0); args[1] =3D gcc_jit_context_new_call(comp.ctxt, NULL, comp.setjmp_ctx_func, 1, args); args[0] =3D buf; return emit_call (intern_c_string (STR (SETJMP_NAME)), comp.int_type, 2, = args, false); #endif } In Windows we issue a call to _setjmp with a jmp_buf as first parameter and= the result of calling __builtin_frame_address(0) as second argument. This handles the case where setjmp.h defines setjmp like this: #define setjmp(BUF) _setjmp((BUF), __builtin_frame_address (0)) The rest of the cases need to be added by hand to this function or we need = to find a way to get autoconf to generate this function. We need the name of the setjmp function because it is used in two places: - The freloc table needs to store a pointer to it, and to do it it needs th= e name the macro is hiding. - The emit_call function maps strings to fields in the freloc table. > Then why do we need to tell libgccjit where the GCC installation > lives? AFAIU from what you are saying, libgccjit already knows that. > What am I missing? Because libgccjit tries to find the GCC installation in the path it was giv= en when `configure` was called. I thinking about redistributing a "stub GCC installation" alongside Emacs. > The gcc executable is always on PATH, only the auxiliary programs > (cc1.exe etc.) aren't. Otherwise you couldn't compile programs in > arbitrary directories. What about users that don't have `gcc` in PATH? We are back to the solution= that adds it to PATH before creating the compilation process. > Then I don't understand why it needs any help at all. When I invoke > gcc to compile a program, I don't tell it anything about where the > installation lives, gcc finds that all by itself. Why is libgccjit > different? Because I was thinking about the case in which GCC is not in PATH because t= he user does not have a Mingw installation. In that case we need to help libgc= cjit find the stub GCC installtion. > Same GCC version as what other version? the one used to compile Emacs itself, perhaps? > What is the definition of "the appropriate GCC version" in this > context? E.g., does it have to be exactly the same version as the one > used to build Emacs itself? Or does it mean something else? The GCC that comes from the source tree that libgccjit was built from. Lets say Emacs was built with libgccjit 9.2 and the user has GCC 10.0.0 installed: it would be a very bad idea to use the local installation, AFAIU= . In fact, libgccjit will not even try and it'll fail. Andrea knows the internals of libgccjit way better than me: I am I right? > How will this work in practice? Are you suggesting that we include > part of the GCC installation in the Emacs binary zip file? If so, we > will have to provide also the humongous GCC source tarball on the same > site, to comply with the GPL. That is doable, of course, but very > inconvenient. We should try to find a better way. This is what I was proposing indeed. The strict version requirement seems t= o get in the way of using the system GCC (If there is one. I hadn't thought about= the GPL requirement. El dom., 10 may. 2020 a las 15:22, Eli Zaretskii () escribi= =C3=B3: > > > From: Nicolas B=C3=A9rtolo > > Date: Sun, 10 May 2020 14:50:52 -0300 > > Cc: Andrea Corallo , emacs-devel@gnu.org > > > > > What information do we need, exactly? > > > > We need: > > - The name of the setjmp function. > > - Whether it needs a second parameter, in that case: > > - It can be a gcc builtin, a function call or a NULL constant. > > - If it is a function call or a builtin it may need a parameter. > > This is a NULL constant in all cases I have seen. > > This is known in advance. We already have that knowledge in Emacs, > see HAVE__SETJMP and HAVE_SIGSETJMP used in lisp.h. > > I don't yet understand why we need the _name_ of the setjmp function. > How will this name be used? > > > > What is the definition of " where the gcc installation lives"? What > > > files does libgccjit need from that place, and how does it look for > > > those files? > > > > libgccjit implements generates an assembler file. This is done without = any calls > > to any external program. Then it calls a gcc entry point to finish the = process. > > This calls the same functions that the `gcc` program uses to identify w= here it > > was installed. In particular, it uses constants defined at libgccjit bu= ild time > > (the compiler version, the directories where it was installed, etc.). I= t uses > > that information plus some environment variables: GCC_EXEC_PREFIX, LIBR= ARY_PATH, > > maybe others, to find where the gcc support files are installed: the su= pport > > binaries, libgcc. This is what I meant by "where the gcc installation l= ives". > > > > This logic runs inside the Emacs process that is performing the compila= tion > > process, but it is the same code that would run in a `gcc -print-*` IIU= C. > > > > > IIUC what is needed, it should be relatively easy to glean this > > > information from the output of "gcc -print-file-name=3D" and its ilk. > > > > libgccjit runs the exact same code as gcc would. So this would not help= . > > Then why do we need to tell libgccjit where the GCC installation > lives? AFAIU from what you are saying, libgccjit already knows that. > What am I missing? > > > Moreover, how would Emacs find gcc? We would need to add it to PATH. > > The gcc executable is always on PATH, only the auxiliary programs > (cc1.exe etc.) aren't. Otherwise you couldn't compile programs in > arbitrary directories. > > > > Using the above-mentioned -print-* options to GCC should accomplish > > > the same tasks, because they ask GCC to reveal the places where it > > > finds its auxiliary binaries and support libraries. Isn't it enough > > > to find out the absolute file names of each such file/program, and > > > tell libgccjit to use that absolute file name, instead of using -B? > > > > I do not think that is possible. libgccjit likes to find the files it n= eeds as > > if it was a gcc instance. > > Then I don't understand why it needs any help at all. When I invoke > gcc to compile a program, I don't tell it anything about where the > installation lives, gcc finds that all by itself. Why is libgccjit > different? > > > > I'd like to avoid that: it's a nuisance to have to copy files that > > > way, and users could legitimately have more than one GCC version > > > installed and available at the same time. > > > > AFAIU, we need to use the same GCC version, that is what libgccjit look= s for. > > Same GCC version as what other version? the one used to compile Emacs > itself, perhaps? > > > Using support libraries from different GCC versions may cause weird bug= s. > > Then we are already in trouble, because libgcc comes with each GCC > version and is slightly different from other versions (although it's > supposed to be compatible), and libmingwex and libmingw32 come with > MinGW distribution which is independent of GCC -- users can upgrade > their MinGW installation at will. > > I don't think using libraries from a different GCC version is going to > cause problems, assuming the newer library is binary-compatible to the > old one (if it isn't, the DLL will have a different name, like > libgcc_s_dw2-2.dll vs libgcc_s_dw2-1.dll). > > > > That assumes that Emacs is configured and built on the same system > > > where it is used. That assumption is mostly false for Windows, where > > > many users simply download and install precompiled binaries, or build > > > on one system and then use on several different ones. We should try > > > to find a way of getting this information at run time, not at > > > configure time. And it shouldn't be hard: we can use at run time the > > > same GCC options as the configure script would do. This should be > > > done once, and the result stored in some FOO-directory variable for > > > use when Lisp should be compiled. > > > > This would mean that users would have to download the appropriate GCC v= ersion if > > they want to use native lisp compilation > > What is the definition of "the appropriate GCC version" in this > context? E.g., does it have to be exactly the same version as the one > used to build Emacs itself? Or does it mean something else? > > > By copying the support files into the installation dir we ensure > > that Emacs finds the correct files and it works out of the box for > > users that download a ZIP file. > > How will this work in practice? Are you suggesting that we include > part of the GCC installation in the Emacs binary zip file? If so, we > will have to provide also the humongous GCC source tarball on the same > site, to comply with the GPL. That is doable, of course, but very > inconvenient. We should try to find a better way. > > But this is still too early, I think we first need to understand > exactly what files does libgccjit need to find during compilation and > how. (Well, I guess _I_ need to understand that; apologies for not > being more familiar with these details of the native-comp branch, and > wasting your time on looking into this and describing the findings. > maybe someone else who knows more about this could chime in and make > the progress faster and less tedious.)