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

["Leif Lindholm" <leif.lindholm@linaro.org>]

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