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

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

This topic is discussed in edk2 design meeting. Here is the minutes https://edk2.groups.io/g/announce/topic/31575273

I also collect the image size for OvmfIa32x64 (Bytes). GCC and CLANG enables LTO, VS2015 enables GL. 
OvmfIa32X64 (Bytes)    GCC5      VS2015x86  CLANG8ELF  CLANG8PE
PEIFV (IA32)            0x2ff28    0x2dfe8     0x2a5a8     0x57028
DXEFV (X64)            0x418528  0x429650   0x3ba6f8    0x502900
FVCOMPACT(Compress)  0x1372e8  0x1204d8   0x1177f0    0x116110

The image size shows new CLANG8ELF tool chain to get the smaller image size than GCC5 and VS2015x86 tool chain. So, I prefer to add CLANG8ELF tool chain first. Then, I will continue to investigate CLANG8PE tool chain and how to generate the different format debug symbol. If no other comments, I plan to add this tool chain for Q2 stable tag. 

Thanks
Liming
> -----Original Message-----
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Liming Gao
> Sent: Sunday, May 5, 2019 2:19 PM
> To: devel@edk2.groups.io; leif.lindholm@linaro.org
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Subject: Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8
> 
> >-----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
> >
> >
> 
> 
>