Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8

["Liming Gao" <liming.gao@intel.com>]

>-----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.gao@intel.com>
>Cc: Ard Biesheuvel <ard.biesheuvel@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
>
>