BaseTools/Source/C/GenFw/Elf32Convert.c | 12 +--- BaseTools/Source/C/GenFw/Elf64Convert.c | 11 +-- BaseTools/Conf/build_rule.template | 8 +-- BaseTools/Conf/tools_def.template | 121 +++++++++++++++++++++++++++++--- BaseTools/Scripts/ClangBase.lds | 79 +++++++++++++++++++++ OvmfPkg/OvmfPkgIa32.dsc | 4 +- OvmfPkg/OvmfPkgIa32.fdf | 2 +- OvmfPkg/OvmfPkgIa32X64.dsc | 4 +- OvmfPkg/OvmfPkgIa32X64.fdf | 2 +- OvmfPkg/OvmfPkgX64.dsc | 4 +- OvmfPkg/OvmfPkgX64.fdf | 2 +- 11 files changed, 213 insertions(+), 36 deletions(-) create mode 100644 BaseTools/Scripts/ClangBase.lds
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1603
LLVM/CLANG8 formal release http://releases.llvm.org/download.html#8.0.0
It can be downloaded and installed in Windows/Linux/Mac OS.
CLANG8ELF tool chain is added to generate ELF image, and convert to PE/COFF.
On Windows OS, set CLANG_HOST_BIN=n, set CLANG8_BIN=LLVM installed directory
CLANG_HOST_BIN is used CLANG_HOST_PREFIX. Prefix n is for nmake.
For example:
set CLANG_HOST_BIN=n
set CLANG8_BIN=C:\Program Files\LLVM\bin\
On Linux/Mac, export CLANG8_BIN=LLVM installed directory, CLANG_HOST_BIN is
not required, because there is no prefix for make.
For example:
export CLANG8_BIN=/home/clang8/bin/
This tool chain can be used to compile the firmware code. On windows OS,
Visual Studio is still required to compile BaseTools C tools and
provide nmake.exe for makefile. On Linux/Mac OS, gcc is used to compile
BaseTools C tools. make is used for makefile.
This tool chain is verified on OVMF Ia32, X64 and Ia32X64 to boot Shell.
This tool chain is verified in Windows/Linux and Mac OS.
Liming Gao (7):
BaseTools: Add ClangBase.lds for CLANG8 tool chain with max-page-size
BaseTools GenFw: Support CLANG8ELF with conversion ELF to PE/COFF
image
BaseTools: Update build_rule.template for ASLC rule with full C flags
BaseTools: Update build_rule to skip CLANG resource section generation
BaseTools: Update tools_def.template to directly refer to AutoGen.h
BaseTools: Add new CLANG8ELF tool chain for new LLVM/CLANG8
OvmfPkg: Update DSC/FDF to support CLANG8ELF tool chain
BaseTools/Source/C/GenFw/Elf32Convert.c | 12 +---
BaseTools/Source/C/GenFw/Elf64Convert.c | 11 +--
BaseTools/Conf/build_rule.template | 8 +--
BaseTools/Conf/tools_def.template | 121 +++++++++++++++++++++++++++++---
BaseTools/Scripts/ClangBase.lds | 79 +++++++++++++++++++++
OvmfPkg/OvmfPkgIa32.dsc | 4 +-
OvmfPkg/OvmfPkgIa32.fdf | 2 +-
OvmfPkg/OvmfPkgIa32X64.dsc | 4 +-
OvmfPkg/OvmfPkgIa32X64.fdf | 2 +-
OvmfPkg/OvmfPkgX64.dsc | 4 +-
OvmfPkg/OvmfPkgX64.fdf | 2 +-
11 files changed, 213 insertions(+), 36 deletions(-)
create mode 100644 BaseTools/Scripts/ClangBase.lds
--
2.13.0.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#39645): https://edk2.groups.io/g/devel/message/39645
Mute This Topic: https://groups.io/mt/31354044/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
On Fri, 26 Apr 2019 at 16:43, Liming Gao <liming.gao@intel.com> wrote: > > BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1603 > LLVM/CLANG8 formal release http://releases.llvm.org/download.html#8.0.0 > It can be downloaded and installed in Windows/Linux/Mac OS. > > CLANG8ELF tool chain is added to generate ELF image, and convert to PE/COFF. > On Windows OS, set CLANG_HOST_BIN=n, set CLANG8_BIN=LLVM installed directory > CLANG_HOST_BIN is used CLANG_HOST_PREFIX. Prefix n is for nmake. > For example: > set CLANG_HOST_BIN=n > set CLANG8_BIN=C:\Program Files\LLVM\bin\ > On Linux/Mac, export CLANG8_BIN=LLVM installed directory, CLANG_HOST_BIN is > not required, because there is no prefix for make. > For example: > export CLANG8_BIN=/home/clang8/bin/ > > This tool chain can be used to compile the firmware code. On windows OS, > Visual Studio is still required to compile BaseTools C tools and > provide nmake.exe for makefile. On Linux/Mac OS, gcc is used to compile > BaseTools C tools. make is used for makefile. > > This tool chain is verified on OVMF Ia32, X64 and Ia32X64 to boot Shell. > This tool chain is verified in Windows/Linux and Mac OS. > Hello Liming, This series confuses me. The existing CLANGxx toolchains already use GenFw and ELF to PE/COFF conversion, so the name CLANG8ELF is misleading. 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. Thanks, Ard. > Liming Gao (7): > BaseTools: Add ClangBase.lds for CLANG8 tool chain with max-page-size > BaseTools GenFw: Support CLANG8ELF with conversion ELF to PE/COFF > image > BaseTools: Update build_rule.template for ASLC rule with full C flags > BaseTools: Update build_rule to skip CLANG resource section generation > BaseTools: Update tools_def.template to directly refer to AutoGen.h > BaseTools: Add new CLANG8ELF tool chain for new LLVM/CLANG8 > OvmfPkg: Update DSC/FDF to support CLANG8ELF tool chain > > BaseTools/Source/C/GenFw/Elf32Convert.c | 12 +--- > BaseTools/Source/C/GenFw/Elf64Convert.c | 11 +-- > BaseTools/Conf/build_rule.template | 8 +-- > BaseTools/Conf/tools_def.template | 121 +++++++++++++++++++++++++++++--- > BaseTools/Scripts/ClangBase.lds | 79 +++++++++++++++++++++ > OvmfPkg/OvmfPkgIa32.dsc | 4 +- > OvmfPkg/OvmfPkgIa32.fdf | 2 +- > OvmfPkg/OvmfPkgIa32X64.dsc | 4 +- > OvmfPkg/OvmfPkgIa32X64.fdf | 2 +- > OvmfPkg/OvmfPkgX64.dsc | 4 +- > OvmfPkg/OvmfPkgX64.fdf | 2 +- > 11 files changed, 213 insertions(+), 36 deletions(-) > create mode 100644 BaseTools/Scripts/ClangBase.lds > > -- > 2.13.0.windows.1 > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#39654): https://edk2.groups.io/g/devel/message/39654 Mute This Topic: https://groups.io/mt/31354044/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
Ard: I add my comments. Thanks Liming >-----Original Message----- >From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] >Sent: Saturday, April 27, 2019 12:33 AM >To: edk2-devel-groups-io <devel@edk2.groups.io>; Gao, Liming ><liming.gao@intel.com> >Subject: Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new >LLVM/CLANG8 > >On Fri, 26 Apr 2019 at 16:43, Liming Gao <liming.gao@intel.com> wrote: >> >> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1603 >> LLVM/CLANG8 formal release >http://releases.llvm.org/download.html#8.0.0 >> It can be downloaded and installed in Windows/Linux/Mac OS. >> >> CLANG8ELF tool chain is added to generate ELF image, and convert to >PE/COFF. >> On Windows OS, set CLANG_HOST_BIN=n, set CLANG8_BIN=LLVM installed >directory >> CLANG_HOST_BIN is used CLANG_HOST_PREFIX. Prefix n is for nmake. >> For example: >> set CLANG_HOST_BIN=n >> set CLANG8_BIN=C:\Program Files\LLVM\bin\ >> On Linux/Mac, export CLANG8_BIN=LLVM installed directory, >CLANG_HOST_BIN is >> not required, because there is no prefix for make. >> For example: >> export CLANG8_BIN=/home/clang8/bin/ >> >> This tool chain can be used to compile the firmware code. On windows OS, >> Visual Studio is still required to compile BaseTools C tools and >> provide nmake.exe for makefile. On Linux/Mac OS, gcc is used to compile >> BaseTools C tools. make is used for makefile. >> >> This tool chain is verified on OVMF Ia32, X64 and Ia32X64 to boot Shell. >> This tool chain is verified in Windows/Linux and Mac OS. >> > >Hello Liming, > >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. 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. >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. > >Thanks, >Ard. > > > >> Liming Gao (7): >> BaseTools: Add ClangBase.lds for CLANG8 tool chain with max-page-size >> BaseTools GenFw: Support CLANG8ELF with conversion ELF to PE/COFF >> image >> BaseTools: Update build_rule.template for ASLC rule with full C flags >> BaseTools: Update build_rule to skip CLANG resource section generation >> BaseTools: Update tools_def.template to directly refer to AutoGen.h >> BaseTools: Add new CLANG8ELF tool chain for new LLVM/CLANG8 >> OvmfPkg: Update DSC/FDF to support CLANG8ELF tool chain >> >> BaseTools/Source/C/GenFw/Elf32Convert.c | 12 +--- >> BaseTools/Source/C/GenFw/Elf64Convert.c | 11 +-- >> BaseTools/Conf/build_rule.template | 8 +-- >> BaseTools/Conf/tools_def.template | 121 >+++++++++++++++++++++++++++++--- >> BaseTools/Scripts/ClangBase.lds | 79 +++++++++++++++++++++ >> OvmfPkg/OvmfPkgIa32.dsc | 4 +- >> OvmfPkg/OvmfPkgIa32.fdf | 2 +- >> OvmfPkg/OvmfPkgIa32X64.dsc | 4 +- >> OvmfPkg/OvmfPkgIa32X64.fdf | 2 +- >> OvmfPkg/OvmfPkgX64.dsc | 4 +- >> OvmfPkg/OvmfPkgX64.fdf | 2 +- >> 11 files changed, 213 insertions(+), 36 deletions(-) >> create mode 100644 BaseTools/Scripts/ClangBase.lds >> >> -- >> 2.13.0.windows.1 >> >> >> >> -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#39701): https://edk2.groups.io/g/devel/message/39701 Mute This Topic: https://groups.io/mt/31354044/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Sun, Apr 28, 2019 at 12:55:02AM +0000, Liming Gao wrote:
> >> This tool chain can be used to compile the firmware code. On windows OS,
> >> Visual Studio is still required to compile BaseTools C tools and
> >> provide nmake.exe for makefile. On Linux/Mac OS, gcc is used to compile
> >> BaseTools C tools. make is used for makefile.
> >>
> >> This tool chain is verified on OVMF Ia32, X64 and Ia32X64 to boot Shell.
> >> This tool chain is verified in Windows/Linux and Mac OS.
> >
> >Hello Liming,
> >
> >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.)
> 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?
> >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?
When developing under Linux, I will use the toolchain provided by my
distribution.
/
Leif
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#39792): https://edk2.groups.io/g/devel/message/39792
Mute This Topic: https://groups.io/mt/31354044/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
> -----Original Message----- > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Leif Lindholm > Sent: Tuesday, April 30, 2019 12:51 AM > 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 Sun, Apr 28, 2019 at 12:55:02AM +0000, Liming Gao wrote: > > >> This tool chain can be used to compile the firmware code. On windows OS, > > >> Visual Studio is still required to compile BaseTools C tools and > > >> provide nmake.exe for makefile. On Linux/Mac OS, gcc is used to compile > > >> BaseTools C tools. make is used for makefile. > > >> > > >> This tool chain is verified on OVMF Ia32, X64 and Ia32X64 to boot Shell. > > >> This tool chain is verified in Windows/Linux and Mac OS. > > > > > >Hello Liming, > > > > > >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. It supports Linux only. It requires CLANG source code to be compiled, and be used. CLANG8ELF depends on LLVM 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. > > 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. 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. > > > >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. > When developing under Linux, I will use the toolchain provided by my > distribution. > > / > Leif > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#39821): https://edk2.groups.io/g/devel/message/39821 Mute This Topic: https://groups.io/mt/31354044/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.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
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#39841): https://edk2.groups.io/g/devel/message/39841
Mute This Topic: https://groups.io/mt/31354044/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
> 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.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 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/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
>-----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 > > -=-=-=-=-=-=-=-=-=-=-=- 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/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On 2019-04-27 17:55:02, Liming Gao wrote: > >-----Original Message----- > >From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] > >Sent: Saturday, April 27, 2019 12:33 AM > > > > > >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. 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. Assuming CLANG8ELF and CLANG8PE were functional, would both be needed? It kind of sounds like this a half-finished investigation. I'm guessing that if CLANG8PE produces equal or better code, then it would be preferred. Therefore, shouldn't we just finish the investigation, and add a single CLANG8 toolchain at the end? Or, maybe to reflect that it mostly uses the LLVM tool stack we could name it LLVM8. -Jordan -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#40985): https://edk2.groups.io/g/devel/message/40985 Mute This Topic: https://groups.io/mt/31354044/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
Jordan: > -----Original Message----- > From: Justen, Jordan L > Sent: Monday, May 20, 2019 4:15 AM > To: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Gao, Liming <liming.gao@intel.com>; edk2-devel-groups-io <devel@edk2.groups.io> > Subject: Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8 > > On 2019-04-27 17:55:02, Liming Gao wrote: > > >-----Original Message----- > > >From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] > > >Sent: Saturday, April 27, 2019 12:33 AM > > > > > > > > >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. 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. > > Assuming CLANG8ELF and CLANG8PE were functional, would both be needed? > It kind of sounds like this a half-finished investigation. > One point is that they will generate the different debug format symbols (WinDBG or GDB). I have not done the full investigation to generate the different debug format symbols in single tool chain. > I'm guessing that if CLANG8PE produces equal or better code, then it > would be preferred. > > Therefore, shouldn't we just finish the investigation, and add a > single CLANG8 toolchain at the end? Or, maybe to reflect that it > mostly uses the LLVM tool stack we could name it LLVM8. I also prefer single CLANG8 tool chain. I will collect more information and see whether it is possible. Now, I would like to add this tool chain for the developer evaluation. Because I can't address all comments now, I will remove this feature from Q2 stable tag. I will add it into edk2-staging first. > > -Jordan -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#41053): https://edk2.groups.io/g/devel/message/41053 Mute This Topic: https://groups.io/mt/31354044/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
> On May 20, 2019, at 6:47 AM, Liming Gao <liming.gao@intel.com> wrote: > > Jordan: > >> -----Original Message----- >> From: Justen, Jordan L >> Sent: Monday, May 20, 2019 4:15 AM >> To: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Gao, Liming <liming.gao@intel.com>; edk2-devel-groups-io <devel@edk2.groups.io> >> Subject: Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8 >> >> On 2019-04-27 17:55:02, Liming Gao wrote: >>>> -----Original Message----- >>>> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] >>>> Sent: Saturday, April 27, 2019 12:33 AM >>>> >>>> >>>> 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. 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. >> >> Assuming CLANG8ELF and CLANG8PE were functional, would both be needed? >> It kind of sounds like this a half-finished investigation. >> > One point is that they will generate the different debug format symbols (WinDBG or GDB). > I have not done the full investigation to generate the different debug format symbols in single tool chain. > Liming, I don't know the current answer but we moved over to using clang a while back on Mac so here are some general thoughts incase they help your investigation. We had to take a different approach for i386 vs x86_64.: 1) i386 For i386 we used -arch i386 and compiler flags to produce the correct ABI. The thing about using -arch is the target triple defaults to your current machine, thus -arch i386 on a Mac is going to make a Mach-O object. if you use it one Linux it is going to make an ELF, on Windows a PE/COFF. To make this work we add mtoc to CCTOOLS this is a tool that converts Mach-O to PE/COFF. The PE/COFF contains a UUID for the Mach-O and the Mach-O dSYM (kind of like the PDB file) and that is what is used for debugging. You can even load the Mach-O directly into the debugger and do offline investigation of the image at its linked address. 2) x86_64 Since the Mac uses the System V ABI we needed a cross compiler. Clang implements cross compilers via the Triple (this is the -target argument you pass to clang). We actually end up open sourcing a triple that did what we needed. For building on a Mac the triple is: -target x86_64-pc-win32-macho <arch><sub>-<vendor>-<sys>-<abi> < x86_64 ><>-< pc >-< win32 >-< macho > Examples: arch = x86_64, i386, arm, thumb, mips, etc. sub = for ex. on ARM: v5, v6m, v7a, v7m, etc. vendor = pc, apple, nvidia, ibm, etc. sys = none, linux, win32, darwin, cuda, etc. abi = eabi, gnu, android, macho, elf, etc. OK so they expanded the Triple to have 4 fields, so that is kind of naming fail, but they still seem to call it a triple. When we did the port "-DEFIAPI=__attribute__((ms_abi))" was not an option and that is why we ended up having to male our own triple. As far as I can tell __attribute__((ms_abi)) works correctly in the Xcode compiler. To make the debugging work we ended up defining a new CodeView signature [1] to the PE/COFF Debug Directory Entry. At this point the native lldb (llvm debugger) does not know how to load Mach-O DWARF from PE/COFF. We could teach it, but we have not really found a need as we ended up writing debugger scripts to load symbols and lldb can load the Mach-O image (our build system leaves them around) for offline debugging. In terms of PDB vs DWARF generally the compiler emits the DWARF (or PDB) data at compile time and the linker just aggregates it together. I see a blog from last April [2] talking about LLVM PDB support and it ends with "Do I hear cross-compilation?". So you might have to compile from the start for PDB or DWARF. This seems to imply you are going to need a triple to invoke a cross compiler? Also you are going to need that triple present in the clang binary, so you might be able to make a custom version of clang that supports the triples you need, but that may not be in the official binary for clang. Converting ELF to PE/COFF is much more straight forward than converting the debugging information so that makes sense that it could just be the backend of the linker. I look forward to getting the results of your investigation. [1] https://github.com/tianocore/edk2/blob/master/MdePkg/Include/IndustryStandard/PeImage.h#L647 [2] http://blog.llvm.org/2017/08/llvm-on-windows-now-supports-pdb-debug.html Thanks, Andrew Fish >> I'm guessing that if CLANG8PE produces equal or better code, then it >> would be preferred. >> >> Therefore, shouldn't we just finish the investigation, and add a >> single CLANG8 toolchain at the end? Or, maybe to reflect that it >> mostly uses the LLVM tool stack we could name it LLVM8. > I also prefer single CLANG8 tool chain. I will collect more information and see whether it is possible. > Now, I would like to add this tool chain for the developer evaluation. Because I can't address all > comments now, I will remove this feature from Q2 stable tag. I will add it into edk2-staging first. > >> >> -Jordan > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#41091): https://edk2.groups.io/g/devel/message/41091 Mute This Topic: https://groups.io/mt/31354044/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
Andrew: Thanks for your sharing. I would like the official LLVM tool chain instead of the customized version. I will investigate it more and go back. Now, I push this patch set into staging https://github.com/tianocore/edk2-staging/tree/llvm8 for the evaluation. Thanks Liming From: afish@apple.com [mailto:afish@apple.com] Sent: Tuesday, May 21, 2019 6:53 AM To: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com> Cc: Justen, Jordan L <jordan.l.justen@intel.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org> Subject: Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8 On May 20, 2019, at 6:47 AM, Liming Gao <liming.gao@intel.com<mailto:liming.gao@intel.com>> wrote: Jordan: -----Original Message----- From: Justen, Jordan L Sent: Monday, May 20, 2019 4:15 AM To: Ard Biesheuvel <ard.biesheuvel@linaro.org<mailto:ard.biesheuvel@linaro.org>>; Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; edk2-devel-groups-io <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> Subject: Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8 On 2019-04-27 17:55:02, Liming Gao wrote: -----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] Sent: Saturday, April 27, 2019 12:33 AM 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. 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. Assuming CLANG8ELF and CLANG8PE were functional, would both be needed? It kind of sounds like this a half-finished investigation. One point is that they will generate the different debug format symbols (WinDBG or GDB). I have not done the full investigation to generate the different debug format symbols in single tool chain. Liming, I don't know the current answer but we moved over to using clang a while back on Mac so here are some general thoughts incase they help your investigation. We had to take a different approach for i386 vs x86_64.: 1) i386 For i386 we used -arch i386 and compiler flags to produce the correct ABI. The thing about using -arch is the target triple defaults to your current machine, thus -arch i386 on a Mac is going to make a Mach-O object. if you use it one Linux it is going to make an ELF, on Windows a PE/COFF. To make this work we add mtoc to CCTOOLS this is a tool that converts Mach-O to PE/COFF. The PE/COFF contains a UUID for the Mach-O and the Mach-O dSYM (kind of like the PDB file) and that is what is used for debugging. You can even load the Mach-O directly into the debugger and do offline investigation of the image at its linked address. 2) x86_64 Since the Mac uses the System V ABI we needed a cross compiler. Clang implements cross compilers via the Triple (this is the -target argument you pass to clang). We actually end up open sourcing a triple that did what we needed. For building on a Mac the triple is: -target x86_64-pc-win32-macho <arch><sub>-<vendor>-<sys>-<abi> < x86_64 ><>-< pc >-< win32 >-< macho > Examples: arch = x86_64, i386, arm, thumb, mips, etc. sub = for ex. on ARM: v5, v6m, v7a, v7m, etc. vendor = pc, apple, nvidia, ibm, etc. sys = none, linux, win32, darwin, cuda, etc. abi = eabi, gnu, android, macho, elf, etc. OK so they expanded the Triple to have 4 fields, so that is kind of naming fail, but they still seem to call it a triple. When we did the port "-DEFIAPI=__attribute__((ms_abi))" was not an option and that is why we ended up having to male our own triple. As far as I can tell __attribute__((ms_abi)) works correctly in the Xcode compiler. To make the debugging work we ended up defining a new CodeView signature [1] to the PE/COFF Debug Directory Entry. At this point the native lldb (llvm debugger) does not know how to load Mach-O DWARF from PE/COFF. We could teach it, but we have not really found a need as we ended up writing debugger scripts to load symbols and lldb can load the Mach-O image (our build system leaves them around) for offline debugging. In terms of PDB vs DWARF generally the compiler emits the DWARF (or PDB) data at compile time and the linker just aggregates it together. I see a blog from last April [2] talking about LLVM PDB support and it ends with "Do I hear cross-compilation?". So you might have to compile from the start for PDB or DWARF. This seems to imply you are going to need a triple to invoke a cross compiler? Also you are going to need that triple present in the clang binary, so you might be able to make a custom version of clang that supports the triples you need, but that may not be in the official binary for clang. Converting ELF to PE/COFF is much more straight forward than converting the debugging information so that makes sense that it could just be the backend of the linker. I look forward to getting the results of your investigation. [1] https://github.com/tianocore/edk2/blob/master/MdePkg/Include/IndustryStandard/PeImage.h#L647 [2] http://blog.llvm.org/2017/08/llvm-on-windows-now-supports-pdb-debug.html Thanks, Andrew Fish I'm guessing that if CLANG8PE produces equal or better code, then it would be preferred. Therefore, shouldn't we just finish the investigation, and add a single CLANG8 toolchain at the end? Or, maybe to reflect that it mostly uses the LLVM tool stack we could name it LLVM8. I also prefer single CLANG8 tool chain. I will collect more information and see whether it is possible. Now, I would like to add this tool chain for the developer evaluation. Because I can't address all comments now, I will remove this feature from Q2 stable tag. I will add it into edk2-staging first. -Jordan -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#41098): https://edk2.groups.io/g/devel/message/41098 Mute This Topic: https://groups.io/mt/31354044/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
> On May 20, 2019, at 7:18 PM, Liming Gao <liming.gao@intel.com> wrote: > > Andrew: > Thanks for your sharing. I would like the official LLVM tool chain instead of the customized version. > Liming, Hopefully all the bits are in place so you can cross compile for Linux on Windows, and Windows on Linux so you will not need a customer binary. If not that seems like something reasonable to ask for, bur remember some one is going to ask for tests. On thing to try is to get the default triple on Linux and try it Window, and get the default triple on Windows and try it on Linux. if you `clang -v` that should print out the default triple. From this writeup [1] some of the 4 fields in the triple can get skipped. You can then try to build the Windows triple on Linux etc. One of the good things about the edk2 is there is not a dependency on the include files or runtime so you just need to make the compiler/linker do the right thing. [1] https://clang.llvm.org/docs/CrossCompilation.html Thanks, Andrew Fish > I will investigate it more and go back. Now, I push this patch set into staging https://github.com/tianocore/edk2-staging/tree/llvm8 <https://github.com/tianocore/edk2-staging/tree/llvm8> for the evaluation. > > Thanks > Liming <> > <>From: afish@apple.com <mailto:afish@apple.com> [mailto:afish@apple.com <mailto:afish@apple.com>] > Sent: Tuesday, May 21, 2019 6:53 AM > To: devel@edk2.groups.io <mailto:devel@edk2.groups.io>; Gao, Liming <liming.gao@intel.com <mailto:liming.gao@intel.com>> > Cc: Justen, Jordan L <jordan.l.justen@intel.com <mailto:jordan.l.justen@intel.com>>; Ard Biesheuvel <ard.biesheuvel@linaro.org <mailto:ard.biesheuvel@linaro.org>> > Subject: Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8 > > > > > On May 20, 2019, at 6:47 AM, Liming Gao <liming.gao@intel.com <mailto:liming.gao@intel.com>> wrote: > > Jordan: > > > -----Original Message----- > From: Justen, Jordan L > Sent: Monday, May 20, 2019 4:15 AM > To: Ard Biesheuvel <ard.biesheuvel@linaro.org <mailto:ard.biesheuvel@linaro.org>>; Gao, Liming <liming.gao@intel.com <mailto:liming.gao@intel.com>>; edk2-devel-groups-io <devel@edk2.groups.io <mailto:devel@edk2.groups.io>> > Subject: Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8 > > On 2019-04-27 17:55:02, Liming Gao wrote: > > -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org <mailto:ard.biesheuvel@linaro.org>] > Sent: Saturday, April 27, 2019 12:33 AM > > > 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. 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. > > Assuming CLANG8ELF and CLANG8PE were functional, would both be needed? > It kind of sounds like this a half-finished investigation. > > One point is that they will generate the different debug format symbols (WinDBG or GDB). > I have not done the full investigation to generate the different debug format symbols in single tool chain. > > > > Liming, > > I don't know the current answer but we moved over to using clang a while back on Mac so here are some general thoughts incase they help your investigation. > > We had to take a different approach for i386 vs x86_64.: > 1) i386 > For i386 we used -arch i386 and compiler flags to produce the correct ABI. The thing about using -arch is the target triple defaults to your current machine, thus -arch i386 on a Mac is going to make a Mach-O object. if you use it one Linux it is going to make an ELF, on Windows a PE/COFF. To make this work we add mtoc to CCTOOLS this is a tool that converts Mach-O to PE/COFF. The PE/COFF contains a UUID for the Mach-O and the Mach-O dSYM (kind of like the PDB file) and that is what is used for debugging. You can even load the Mach-O directly into the debugger and do offline investigation of the image at its linked address. > > 2) x86_64 > Since the Mac uses the System V ABI we needed a cross compiler. Clang implements cross compilers via the Triple (this is the -target argument you pass to clang). We actually end up open sourcing a triple that did what we needed. > > For building on a Mac the triple is: -target x86_64-pc-win32-macho > > <arch><sub>-<vendor>-<sys>-<abi> > < x86_64 ><>-< pc >-< win32 >-< macho > > > Examples: > arch = x86_64, i386, arm, thumb, mips, etc. > sub = for ex. on ARM: v5, v6m, v7a, v7m, etc. > vendor = pc, apple, nvidia, ibm, etc. > sys = none, linux, win32, darwin, cuda, etc. > abi = eabi, gnu, android, macho, elf, etc. > > OK so they expanded the Triple to have 4 fields, so that is kind of naming fail, but they still seem to call it a triple. When we did the port "-DEFIAPI=__attribute__((ms_abi))" was not an option and that is why we ended up having to male our own triple. As far as I can tell __attribute__((ms_abi)) works correctly in the Xcode compiler. > > To make the debugging work we ended up defining a new CodeView signature [1] to the PE/COFF Debug Directory Entry. At this point the native lldb (llvm debugger) does not know how to load Mach-O DWARF from PE/COFF. We could teach it, but we have not really found a need as we ended up writing debugger scripts to load symbols and lldb can load the Mach-O image (our build system leaves them around) for offline debugging. > > In terms of PDB vs DWARF generally the compiler emits the DWARF (or PDB) data at compile time and the linker just aggregates it together. I see a blog from last April [2] talking about LLVM PDB support and it ends with "Do I hear cross-compilation?". So you might have to compile from the start for PDB or DWARF. This seems to imply you are going to need a triple to invoke a cross compiler? Also you are going to need that triple present in the clang binary, so you might be able to make a custom version of clang that supports the triples you need, but that may not be in the official binary for clang. > > Converting ELF to PE/COFF is much more straight forward than converting the debugging information so that makes sense that it could just be the backend of the linker. > > I look forward to getting the results of your investigation. > > [1] https://github.com/tianocore/edk2/blob/master/MdePkg/Include/IndustryStandard/PeImage.h#L647 <https://github.com/tianocore/edk2/blob/master/MdePkg/Include/IndustryStandard/PeImage.h#L647> > [2] http://blog.llvm.org/2017/08/llvm-on-windows-now-supports-pdb-debug.html <http://blog.llvm.org/2017/08/llvm-on-windows-now-supports-pdb-debug.html> > > Thanks, > > Andrew Fish > > I'm guessing that if CLANG8PE produces equal or better code, then it > would be preferred. > > Therefore, shouldn't we just finish the investigation, and add a > single CLANG8 toolchain at the end? Or, maybe to reflect that it > mostly uses the LLVM tool stack we could name it LLVM8. > I also prefer single CLANG8 tool chain. I will collect more information and see whether it is possible. > Now, I would like to add this tool chain for the developer evaluation. Because I can't address all > comments now, I will remove this feature from Q2 stable tag. I will add it into edk2-staging first. > > > -Jordan > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#41112): https://edk2.groups.io/g/devel/message/41112 Mute This Topic: https://groups.io/mt/31354044/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On 04/26/19 16:42, Liming Gao wrote: > BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1603 > LLVM/CLANG8 formal release http://releases.llvm.org/download.html#8.0.0 > It can be downloaded and installed in Windows/Linux/Mac OS. > > CLANG8ELF tool chain is added to generate ELF image, and convert to PE/COFF. > On Windows OS, set CLANG_HOST_BIN=n, set CLANG8_BIN=LLVM installed directory > CLANG_HOST_BIN is used CLANG_HOST_PREFIX. Prefix n is for nmake. > For example: > set CLANG_HOST_BIN=n > set CLANG8_BIN=C:\Program Files\LLVM\bin\ > On Linux/Mac, export CLANG8_BIN=LLVM installed directory, CLANG_HOST_BIN is > not required, because there is no prefix for make. > For example: > export CLANG8_BIN=/home/clang8/bin/ > > This tool chain can be used to compile the firmware code. On windows OS, > Visual Studio is still required to compile BaseTools C tools and > provide nmake.exe for makefile. On Linux/Mac OS, gcc is used to compile > BaseTools C tools. make is used for makefile. > > This tool chain is verified on OVMF Ia32, X64 and Ia32X64 to boot Shell. > This tool chain is verified in Windows/Linux and Mac OS. > > Liming Gao (7): > BaseTools: Add ClangBase.lds for CLANG8 tool chain with max-page-size > BaseTools GenFw: Support CLANG8ELF with conversion ELF to PE/COFF > image > BaseTools: Update build_rule.template for ASLC rule with full C flags > BaseTools: Update build_rule to skip CLANG resource section generation > BaseTools: Update tools_def.template to directly refer to AutoGen.h > BaseTools: Add new CLANG8ELF tool chain for new LLVM/CLANG8 > OvmfPkg: Update DSC/FDF to support CLANG8ELF tool chain > > BaseTools/Source/C/GenFw/Elf32Convert.c | 12 +--- > BaseTools/Source/C/GenFw/Elf64Convert.c | 11 +-- > BaseTools/Conf/build_rule.template | 8 +-- > BaseTools/Conf/tools_def.template | 121 +++++++++++++++++++++++++++++--- > BaseTools/Scripts/ClangBase.lds | 79 +++++++++++++++++++++ > OvmfPkg/OvmfPkgIa32.dsc | 4 +- > OvmfPkg/OvmfPkgIa32.fdf | 2 +- > OvmfPkg/OvmfPkgIa32X64.dsc | 4 +- > OvmfPkg/OvmfPkgIa32X64.fdf | 2 +- > OvmfPkg/OvmfPkgX64.dsc | 4 +- > OvmfPkg/OvmfPkgX64.fdf | 2 +- > 11 files changed, 213 insertions(+), 36 deletions(-) > create mode 100644 BaseTools/Scripts/ClangBase.lds > This feature has missed edk2-stable201905. Please postpone the following BZ reference: https://bugzilla.tianocore.org/show_bug.cgi?id=1603 from https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning#edk2-stable201905-tag-planning to https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning#edk2-stable201908-tag-planning Thanks, Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#41171): https://edk2.groups.io/g/devel/message/41171 Mute This Topic: https://groups.io/mt/31354044/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
© 2016 - 2024 Red Hat, Inc.