From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 134.134.136.126, mailfrom: liming.gao@intel.com) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by groups.io with SMTP; Sat, 04 May 2019 23:18:50 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 May 2019 23:18:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,431,1549958400"; d="scan'208";a="167929139" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga004.fm.intel.com with ESMTP; 04 May 2019 23:18:49 -0700 Received: from fmsmsx116.amr.corp.intel.com (10.18.116.20) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 4 May 2019 23:18:48 -0700 Received: from shsmsx105.ccr.corp.intel.com (10.239.4.158) by fmsmsx116.amr.corp.intel.com (10.18.116.20) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 4 May 2019 23:18:48 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.33]) by SHSMSX105.ccr.corp.intel.com ([169.254.11.10]) with mapi id 14.03.0415.000; Sun, 5 May 2019 14:18:46 +0800 From: "Liming Gao" To: "devel@edk2.groups.io" , "leif.lindholm@linaro.org" CC: Ard Biesheuvel Subject: Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8 Thread-Topic: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8 Thread-Index: AQHU/E3ClCQnniT0z0eoB13gdfWnb6ZQvUVAgAIbkgCAATnOQP//9ruAgAgEULA= Date: Sun, 5 May 2019 06:18:45 +0000 Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14E4412DF@SHSMSX104.ccr.corp.intel.com> References: <20190426144242.19024-1-liming.gao@intel.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E431937@SHSMSX104.ccr.corp.intel.com> <20190429165124.cnacggdw4guz2e64@bivouac.eciton.net> <4A89E2EF3DFEDB4C8BFDE51014F606A14E43FCA8@SHSMSX104.ccr.corp.intel.com> <20190430110123.lbmuqap64ll3wsyk@bivouac.eciton.net> In-Reply-To: <20190430110123.lbmuqap64ll3wsyk@bivouac.eciton.net> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: liming.gao@intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >-----Original Message----- >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Lei= f >Lindholm >Sent: Tuesday, April 30, 2019 7:01 PM >To: devel@edk2.groups.io; Gao, Liming >Cc: Ard Biesheuvel >Subject: Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for ne= w >LLVM/CLANG8 > >On Tue, Apr 30, 2019 at 04:21:29AM +0000, Liming Gao wrote: >> > > >This series confuses me. The existing CLANGxx toolchains already u= se >> > > >GenFw and ELF to PE/COFF conversion, so the name CLANG8ELF is >> > > >misleading. >> > > > >> > > LLVM/CLANG8.0 compiler supports to generate PE image or ELF >> > > image. This tool chain is to generate ELF image and be converted to >> > > PE image. >> > >> > Which is what CLANG38 does - so why do we need a completely new >> > toolchain profile? (Shortly after we got rid of a bunch of unneeded >> > ones.) >> > >> CLANG38 depends on GNU binutils linker. > >Yes. > >> It supports Linux only. > >Really? >I mean, I haven't tested it on Windows, but I don't think there is any >fundamental limitation that should prevent it from working? It may work on Windows. But, no one try the step.=20 > >> It requires CLANG source code to be compiled, and be used. > >OK, that is inconvenient. >I think you can get it through cygwin, but that creates other problems. > >> CLANG8ELF depends on LLVM LLD. > >I would flip that statement. >It enables the use of LLD. Yes. > >> LLVM/CLANG release provides the prebuilt binaries >> for Windows/Linux/Mac. It is easy for user to setup the >> environment. User can also use this tool chain in the different OS. > >It was always my understanding that this was the intent of the CLANG## >profiles. So I do not see this as an added benefit. > Yes. Easy use single tool chain is the main purpose. >> > > I am investigating another tool chain with CLANG8.0 to >> > > directly generate PE image. To differentiate them, I use the tool >> > > chain name CLANG8ELF and CLANG8PE for them. >> > >> > Why do we want two different toolchain profiles that generate >> > identical output in different ways, using the same tools? >> >> Generate the different debug symbols (DWARF, PDB) for the different >> debugger. Windows user may use WinDbg for the source level >> debug. > >OK, this is a big deal, and I wish this had been mentioned both in the >https://bugzilla.tianocore.org/show_bug.cgi?id=3D1603 and the patch >submission. > >The bugzilla entry reads to me only like "add CLANG8 profile" or "make >sure CLANG38 profile works with clang 8".. > Sorry for this confuse. I add such information in BZ. >> Generate the different executable image to run Emulator in Windows >> or Linux. >> >> I need that CLANG8 tool chain provides the same functionality to >> VS2015, GCC and XCODE tool chain. If so, the developer can use the >> single tool chain for his development. > >Again, I don't see this as being any different from what CLANG38 >already gives us. The difference is linker LLD or LD. > >> > > >Also, it seems that the primary difference is using LLD instead of= GNU >> > > >ld, but this has nothing to do with the Clang version. >> > > > >> > > >What is the benefit of using LLD over GNU ld? It seems we are work= ing >> > > >around various incompatibilities, and I think this is only justifi= ed >> > > >if LLD has some benefit over GNU ld. >> > > >> > > LLD is part of LLVM/CLANG8 tool set. User can get all required >> > > compilers and linkers from >> > > http://releases.llvm.org/download.html#8.0.0. >> > > LLVM8 release includes Windows/Linux/Mac version. User can >download >> > > it and install them together. This tool chain is the unified tool >> > > chain to be used in Windows/Linux/Mac OS. >> > >> > Can we note already build under all of these operating systems with >> > the GNU binutils linker? >> >> I am not sure. Now, I use VS2015 on Windows OS, use GCC5 on Linux >> OS, and XCODE5 on Mac OS. >> VS2015 and XCODE5 doesn't use GNU binutils linker. > >Indeed. > >So, to summarise - I am all for adding a toolchain profile that uses >clang with lld (this is also available with Linux distribution >packaged toolchains). But that is what we're doing - the fact that it's >version 8 of clang is beside the point. >If we cannot do this with a profile called CLANG8, then I would prefer >if we can call it LLDCLANG#. Yes. New tool chain will use LLD linker. I find previous version LLD has o= ne issue https://bugs.llvm.org/show_bug.cgi?id=3D39810. It causes the build failure= in edk2 build.=20 This issue is fixed in LLVM8.0 release. So, I name this tool chain as CLAN= G8.=20 I am OK to add LLD in tool chain name. So, new tool chain will be LLDCLANG= 8ELF.=20 > >I think if we are able to add another profile for native PE (and PDB), >that would be excellent. But the name ought to emphasise what the >functional difference in the output is rather than what the >intermediate steps are. Yes. This is also in my plan.=20 > >/ > Leif > >