> I think if we are able to add another profile for native PE (and PDB), that > 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 progress is in below link: https://github.com/shijunjing/edk2/wiki/Enable-clang-COFF-native-build-toolchain-in-edk2
The lld blocking bug: http://lists.llvm.org/pipermail/llvm-dev/2019-February/130632.html The llvm linker owner suggest me to use clang-cl (clang MSVC interface compiler) + lld-link (llvm COFF linker) solution to directly produce the COFF native executable for Uefi in both Linux and Windows, which can avoid the ELF complex relocation convent and make the Linux build much easier. The "clang-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/2019-January/129749.html Thanks Steven Shi Intel\SSG\FID\Firmware Infrastructure > -----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 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. > > > 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. > > > > > 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".. > > > 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. > > > > > >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#. > > 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. > > / > Leif > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#39849): https://edk2.groups.io/g/devel/message/39849 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] -=-=-=-=-=-=-=-=-=-=-=-
