From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] [WIP] Port feature/native-comp to Windows. Date: Sun, 10 May 2020 20:08:59 +0300 Message-ID: <83lflzd8es.fsf@gnu.org> References: <5eb5b953.1c69fb81.a67ce.a764@mx.google.com> <83lfm1hc91.fsf@gnu.org> <83wo5lds87.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="36281"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, akrl@sdf.org To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 10 19:10:01 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 1jXpSj-0009Jv-3R for ged-emacs-devel@m.gmane-mx.org; Sun, 10 May 2020 19:10:01 +0200 Original-Received: from localhost ([::1]:42452 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXpSh-0005Ad-Jc for ged-emacs-devel@m.gmane-mx.org; Sun, 10 May 2020 13:09:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36682) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXpRs-0004bA-29 for emacs-devel@gnu.org; Sun, 10 May 2020 13:09:08 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:46482) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXpRq-0007YZ-Ex; Sun, 10 May 2020 13:09:06 -0400 Original-Received: from [176.228.60.248] (port=4339 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jXpRp-0001L8-PV; Sun, 10 May 2020 13:09:06 -0400 In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Sun, 10 May 2020 13:36:18 -0300) 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:249678 Archived-At: > From: Nicolas Bértolo > Date: Sun, 10 May 2020 13:36:18 -0300 > Cc: Andrea Corallo , emacs-devel@gnu.org > > >> There are many ways to call setjmp() in Windows. It depends on the architecture, > >> whether the Universal CRT is used, whether SEH is enabled, the compiler version, > >> etc. > > > Yes, I know. But we need to support only the way we compile Emacs, > > right? > > Yes, but how do we get that information at build time? What information do we need, exactly? > And then parse the results to see what the setjmp() gets translated into by the > preprocessor. It is a lot of work, that why I suggested doing it with autoconf > somehow. If you could explain in more detail what information is needed and how it is used for compiling to native code, maybe I could think of a reasonable solution. > > And similarly with ld.exe and any other program that GCC needs to > > invoke as party of the compilation. Can we use that instead of adding > > directories to PATH? In fact, I wonder how does the > > native-compilation branch solve this for GNU/Linux systems, if not > > like that? > > gccjit lets us add options to the command line it feeds its internal copy of > GCC. The option "-B path" can be used to define the path where a gcc > installation lives. 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? IIUC what is needed, it should be relatively easy to glean this information from the output of "gcc -print-file-name=" and its ilk. > In GNU/Linux the branch relies on the gcc installation being in the standard > path. That is: libgccjit uses the same logic as gcc to find its binaries > and support libraries (this is why the "-B" switch works). 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? We could also use -B, it is not much more complex, it just needs some manipulation with file names returned by the various -print-* options of GCC to find their common parent directory (which is what I presume is meant by "where the GCC installation lives"). > I think I found a solution. We can setup a "stub gcc installation" in the > directory where Emacs is installed. It should be like this: > > configure --prefix: > - bin/ > - emacs.exe > - etc > - lib/gcc/x86_64-w64-mingw32/10.0.0: > - as.exe > - collect2.exe > - ld.exe > - crtbegin.o > - crtend.o > - dllcrt2.o > - libgcc.a > - libkernel32.a > - libmingw32.a > - libmingwex.a > - libmsvcrt.a 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. I think it is much better to figure out which directory to pass in the "-B" option, or use absolute file names which we receive from GCC. See the node "Developer Options" in the GCC manual, it describes the various -print-* command-line options to GCC which can be used for this purpose. Can we use these to obtain the same information? For example, this command: gcc -print-file-name=libmingwex.a will display the absolute file name of that library in each GCC installation. > The actual name of the directories could be obtained through autoconf and the > files can be copied from the GCC used to build Emacs. 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 is the minimal set of files required to build an eln file. They are > necessary to initialize the CRT in the DLL. Given that the generated code does > not use the CRT, I think we can further reduce the set of libraries used. This > would require adding a function called `DllMainCRTStartup` to the generated > code. It would do nothing, instead of setting up the CRT. > > There is an issue with this approach: this function would need to be generated > with the __stdcall calling convention and there is no way in libgccjit to > specify that. It could be solved using a small object file compiled during the > Emacs build process and then put in the "stub GCC installation". > > What do you think? The last bit sounds fine, but I'd like to avoid the stub GCC thingy. I also think that making the *.eln files depend on fewer DLLs is an optimization that can wait. I suggest first to solve the problem with discovering where GCC is installed so that the compilation could use the correct file names, without requiring copying GCC files into a stub installation. > +#ifdef _WIN32 We use "#ifdef WINDOWSNT" in Emacs, not _WIN32. But that's a minor nit at this stage. Thanks.