>-----Original Message----- >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Leif >Lindholm >Sent: Tuesday, April 30, 2019 7:01 PM >To: devel@edk2.groups.io; Gao, Liming <liming....@intel.com> >Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> >Subject: Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new >LLVM/CLANG8 > >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 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. > >> 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=1603 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 working >> > > >around various incompatibilities, and I think this is only justified >> > > >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 one issue https://bugs.llvm.org/show_bug.cgi?id=39810. It causes the build failure in edk2 build. This issue is fixed in LLVM8.0 release. So, I name this tool chain as CLANG8. I am OK to add LLD in tool chain name. So, new tool chain will be LLDCLANG8ELF. > >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. > >/ > Leif > >
-=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#39993): https://edk2.groups.io/g/devel/message/39993 Mute This Topic: https://groups.io/mt/31354044/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
