From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.120, mailfrom: steven.shi@intel.com) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by groups.io with SMTP; Tue, 30 Apr 2019 06:12:04 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Apr 2019 06:12:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,413,1549958400"; d="scan'208";a="166262457" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga002.fm.intel.com with ESMTP; 30 Apr 2019 06:12:04 -0700 Received: from FMSMSX109.amr.corp.intel.com (10.18.116.9) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 30 Apr 2019 06:12:04 -0700 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by fmsmsx109.amr.corp.intel.com (10.18.116.9) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 30 Apr 2019 06:12:03 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.249]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.70]) with mapi id 14.03.0415.000; Tue, 30 Apr 2019 21:11:40 +0800 From: "Steven Shi" To: "devel@edk2.groups.io" , "leif.lindholm@linaro.org" , "Gao, Liming" 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/D5cxR3BxiqvtECl79TxYrGU3KZOHOyAgAIegACAAp2JAIAAwM+AgABvu4CAAKhe0A== Date: Tue, 30 Apr 2019 13:11:39 +0000 Message-ID: <06C8AB66E78EE34A949939824ABE2B313FFAA636@shsmsx102.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-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiN2I2YjM3MTYtYTYyNy00NmRmLWJlM2EtY2U2ZTdiOTY1NzY3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiNU0xcE5oMnZOTVRvRXhteGowQ3g5YU5QMUxQK2xWU29GSVlpakRCeHJ2ZGl5dEJhRnlOSVlRT2x5Z3hIemRMciJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: steven.shi@intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > I think if we are able to add another profile for native PE (and PDB), th= at would be excellent. We are working on it. Not done yet. Was stuck in a lld bug with LTO on Feb= , but hopefully it will get solved in future lld version. Detail working pr= ogress is in below link: https://github.com/shijunjing/edk2/wiki/Enable-clang-COFF-native-build-too= lchain-in-edk2=20 The lld blocking bug: http://lists.llvm.org/pipermail/llvm-dev/2019-Februa= ry/130632.html=20 The llvm linker owner suggest me to use clang-cl (clang MSVC interface com= piler) + lld-link (llvm COFF linker) solution to directly produce the COFF = native executable for Uefi in both Linux and Windows, which can avoid the E= LF complex relocation convent and make the Linux build much easier. The "cl= ang-cl + lld-link" solution support both PDB and dwarf debug info and looks= can cover all Uefi build and debug requirements. See the background detail here: http://lists.llvm.org/pipermail/llvm-dev/2= 019-January/129749.html=20 Thanks Steven Shi Intel\SSG\FID\Firmware Infrastructure > -----Original Message----- > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Le= if > 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 n= ew > LLVM/CLANG8 >=20 > On Tue, Apr 30, 2019 at 04:21:29AM +0000, Liming Gao wrote: > > > > >This series confuses me. The existing CLANGxx toolchains already = use > > > > >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 t= o > > > > 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. >=20 > Yes. >=20 > > It supports Linux only. >=20 > 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? >=20 > > It requires CLANG source code to be compiled, and be used. >=20 > OK, that is inconvenient. > I think you can get it through cygwin, but that creates other problems. >=20 > > CLANG8ELF depends on LLVM LLD. >=20 > I would flip that statement. > It enables the use of LLD. >=20 > > 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. >=20 > It was always my understanding that this was the intent of the CLANG## > profiles. So I do not see this as an added benefit. >=20 > > > > 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. >=20 > 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. >=20 > The bugzilla entry reads to me only like "add CLANG8 profile" or "make > sure CLANG38 profile works with clang 8".. >=20 > > 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. >=20 > Again, I don't see this as being any different from what CLANG38 > already gives us. >=20 > > > > >Also, it seems that the primary difference is using LLD instead o= f 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 wor= king > > > > >around various incompatibilities, and I think this is only justif= ied > > > > >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 downloa= d > > > > 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. >=20 > Indeed. >=20 > 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#. >=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. >=20 > / > Leif >=20 >=20