* [Patch 1/7] BaseTools: Add ClangBase.lds for CLANG8 tool chain with max-page-size
2019-04-26 14:42 [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8 Liming Gao
@ 2019-04-26 14:42 ` Liming Gao
2019-04-26 14:42 ` [Patch 2/7] BaseTools GenFw: Support CLANG8ELF with conversion ELF to PE/COFF image Liming Gao
` (8 subsequent siblings)
9 siblings, 0 replies; 27+ messages in thread
From: Liming Gao @ 2019-04-26 14:42 UTC (permalink / raw)
To: devel
LLVM LLD linker doesn't support common-page-size option. So, max-page-size
is used. To not impact GCC tool chain, new ClangBase.lds is added.
Signed-off-by: Liming Gao <liming.gao@intel.com>
---
BaseTools/Scripts/ClangBase.lds | 79 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 79 insertions(+)
create mode 100644 BaseTools/Scripts/ClangBase.lds
diff --git a/BaseTools/Scripts/ClangBase.lds b/BaseTools/Scripts/ClangBase.lds
new file mode 100644
index 0000000000..8abd54aee6
--- /dev/null
+++ b/BaseTools/Scripts/ClangBase.lds
@@ -0,0 +1,79 @@
+/** @file
+
+ Unified linker script for GCC based builds
+
+ Copyright (c) 2010 - 2015, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2015, Linaro Ltd. All rights reserved.<BR>
+ (C) Copyright 2016 Hewlett Packard Enterprise Development LP<BR>
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+SECTIONS {
+
+ /*
+ * The PE/COFF binary consists of DOS and PE/COFF headers, and a sequence of
+ * section headers adding up to PECOFF_HEADER_SIZE bytes (which differs
+ * between 32-bit and 64-bit builds). The actual start of the .text section
+ * will be rounded up based on its actual alignment.
+ */
+ . = PECOFF_HEADER_SIZE;
+
+ .text : ALIGN(CONSTANT(MAXPAGESIZE)) {
+ *(.text .text.* .stub .gnu.linkonce.t.*)
+ *(.rodata .rodata.* .gnu.linkonce.r.*)
+ *(.got .got.*)
+
+ /*
+ * The contents of AutoGen.c files are mostly constant from the POV of the
+ * program, but most of it ends up in .data or .bss by default since few of
+ * the variable definitions that get emitted are declared as CONST.
+ * Unfortunately, we cannot pull it into the .text section entirely, since
+ * patchable PCDs are also emitted here, but we can at least move all of the
+ * emitted GUIDs here.
+ */
+ *:AutoGen.obj(.data.g*Guid)
+ }
+
+ /*
+ * The alignment of the .data section should be less than or equal to the
+ * alignment of the .text section. This ensures that the relative offset
+ * between these sections is the same in the ELF and the PE/COFF versions of
+ * this binary.
+ */
+ .data ALIGN(ALIGNOF(.text)) : ALIGN(CONSTANT(MAXPAGESIZE)) {
+ *(.data .data.* .gnu.linkonce.d.*)
+ *(.bss .bss.*)
+ }
+
+ .eh_frame ALIGN(CONSTANT(MAXPAGESIZE)) : {
+ KEEP (*(.eh_frame))
+ }
+
+ .rela (INFO) : {
+ *(.rela .rela.*)
+ }
+
+ .hii : ALIGN(CONSTANT(MAXPAGESIZE)) {
+ KEEP (*(.hii))
+ }
+
+ /*
+ * Retain the GNU build id but in a non-allocatable section so GenFw
+ * does not copy it into the PE/COFF image.
+ */
+ .build-id (INFO) : { *(.note.gnu.build-id) }
+
+ /DISCARD/ : {
+ *(.note.GNU-stack)
+ *(.gnu_debuglink)
+ *(.interp)
+ *(.dynsym)
+ *(.dynstr)
+ *(.dynamic)
+ *(.hash .gnu.hash)
+ *(.comment)
+ *(COMMON)
+ }
+}
--
2.13.0.windows.1
^ permalink raw reply related [flat|nested] 27+ messages in thread* [Patch 2/7] BaseTools GenFw: Support CLANG8ELF with conversion ELF to PE/COFF image
2019-04-26 14:42 [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8 Liming Gao
2019-04-26 14:42 ` [Patch 1/7] BaseTools: Add ClangBase.lds for CLANG8 tool chain with max-page-size Liming Gao
@ 2019-04-26 14:42 ` Liming Gao
2019-04-26 14:42 ` [Patch 3/7] BaseTools: Update build_rule.template for ASLC rule with full C flags Liming Gao
` (7 subsequent siblings)
9 siblings, 0 replies; 27+ messages in thread
From: Liming Gao @ 2019-04-26 14:42 UTC (permalink / raw)
To: devel
CLANG8ELF tool chain generated ELF image with the different attributes
in section. Update GenFw to handle them.
1. .text section with writable attribute (support)
2. .reloc section has the symbol for *ABS* (skip)
Signed-off-by: Liming Gao <liming.gao@intel.com>
---
BaseTools/Source/C/GenFw/Elf32Convert.c | 12 +++---------
BaseTools/Source/C/GenFw/Elf64Convert.c | 11 +++--------
2 files changed, 6 insertions(+), 17 deletions(-)
diff --git a/BaseTools/Source/C/GenFw/Elf32Convert.c b/BaseTools/Source/C/GenFw/Elf32Convert.c
index 46089ff370..fd13278e3d 100644
--- a/BaseTools/Source/C/GenFw/Elf32Convert.c
+++ b/BaseTools/Source/C/GenFw/Elf32Convert.c
@@ -238,7 +238,7 @@ IsTextShdr (
Elf_Shdr *Shdr
)
{
- return (BOOLEAN) ((Shdr->sh_flags & (SHF_WRITE | SHF_ALLOC)) == SHF_ALLOC);
+ return (BOOLEAN) ((Shdr->sh_flags & (SHF_EXECINSTR | SHF_ALLOC)) == (SHF_EXECINSTR | SHF_ALLOC));
}
STATIC
@@ -261,7 +261,7 @@ IsDataShdr (
if (IsHiiRsrcShdr(Shdr)) {
return FALSE;
}
- return (BOOLEAN) (Shdr->sh_flags & (SHF_WRITE | SHF_ALLOC)) == (SHF_ALLOC | SHF_WRITE);
+ return (BOOLEAN) (Shdr->sh_flags & (SHF_EXECINSTR | SHF_WRITE | SHF_ALLOC)) == (SHF_ALLOC | SHF_WRITE);
}
STATIC
@@ -749,13 +749,7 @@ WriteSections32 (
if (SymName == NULL) {
SymName = (const UINT8 *)"<unknown>";
}
-
- Error (NULL, 0, 3000, "Invalid",
- "%s: Bad definition for symbol '%s'@%#x or unsupported symbol type. "
- "For example, absolute and undefined symbols are not supported.",
- mInImageName, SymName, Sym->st_value);
-
- exit(EXIT_FAILURE);
+ continue;
}
SymShdr = GetShdrByIndex(Sym->st_shndx);
diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c b/BaseTools/Source/C/GenFw/Elf64Convert.c
index 3d6319c821..35cebad27d 100644
--- a/BaseTools/Source/C/GenFw/Elf64Convert.c
+++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
@@ -239,7 +239,7 @@ IsTextShdr (
Elf_Shdr *Shdr
)
{
- return (BOOLEAN) ((Shdr->sh_flags & (SHF_WRITE | SHF_ALLOC)) == SHF_ALLOC);
+ return (BOOLEAN) ((Shdr->sh_flags & (SHF_EXECINSTR | SHF_ALLOC)) == (SHF_EXECINSTR | SHF_ALLOC));
}
STATIC
@@ -262,7 +262,7 @@ IsDataShdr (
if (IsHiiRsrcShdr(Shdr)) {
return FALSE;
}
- return (BOOLEAN) (Shdr->sh_flags & (SHF_WRITE | SHF_ALLOC)) == (SHF_ALLOC | SHF_WRITE);
+ return (BOOLEAN) (Shdr->sh_flags & (SHF_EXECINSTR | SHF_WRITE | SHF_ALLOC)) == (SHF_ALLOC | SHF_WRITE);
}
STATIC
@@ -894,12 +894,7 @@ WriteSections64 (
SymName = (const UINT8 *)"<unknown>";
}
- Error (NULL, 0, 3000, "Invalid",
- "%s: Bad definition for symbol '%s'@%#llx or unsupported symbol type. "
- "For example, absolute and undefined symbols are not supported.",
- mInImageName, SymName, Sym->st_value);
-
- exit(EXIT_FAILURE);
+ continue;
}
SymShdr = GetShdrByIndex(Sym->st_shndx);
--
2.13.0.windows.1
^ permalink raw reply related [flat|nested] 27+ messages in thread* [Patch 3/7] BaseTools: Update build_rule.template for ASLC rule with full C flags
2019-04-26 14:42 [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8 Liming Gao
2019-04-26 14:42 ` [Patch 1/7] BaseTools: Add ClangBase.lds for CLANG8 tool chain with max-page-size Liming Gao
2019-04-26 14:42 ` [Patch 2/7] BaseTools GenFw: Support CLANG8ELF with conversion ELF to PE/COFF image Liming Gao
@ 2019-04-26 14:42 ` Liming Gao
2019-04-26 14:42 ` [Patch 4/7] BaseTools: Update build_rule to skip CLANG resource section generation Liming Gao
` (6 subsequent siblings)
9 siblings, 0 replies; 27+ messages in thread
From: Liming Gao @ 2019-04-26 14:42 UTC (permalink / raw)
To: devel
Update ASLC GCC link step with the full C compiler flags. It can make sure
lto option works correctly.
Signed-off-by: Liming Gao <liming.gao@intel.com>
---
BaseTools/Conf/build_rule.template | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/BaseTools/Conf/build_rule.template b/BaseTools/Conf/build_rule.template
index 030e74c35a..43c1b6dd3b 100755
--- a/BaseTools/Conf/build_rule.template
+++ b/BaseTools/Conf/build_rule.template
@@ -460,7 +460,7 @@
<Command.GCC>
"$(ASLCC)" -c -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj $(CC_FLAGS) $(ASLCC_FLAGS) $(INC) ${src}
- "$(ASLDLINK)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll $(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
+ "$(ASLDLINK)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll $(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj $(CC_FLAGS) $(ASLCC_FLAGS)
"$(GENFW)" -o ${dst} -c $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll $(GENFW_FLAGS)
<Command.XCODE>
--
2.13.0.windows.1
^ permalink raw reply related [flat|nested] 27+ messages in thread* [Patch 4/7] BaseTools: Update build_rule to skip CLANG resource section generation
2019-04-26 14:42 [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8 Liming Gao
` (2 preceding siblings ...)
2019-04-26 14:42 ` [Patch 3/7] BaseTools: Update build_rule.template for ASLC rule with full C flags Liming Gao
@ 2019-04-26 14:42 ` Liming Gao
2019-04-26 14:42 ` [Patch 5/7] BaseTools: Update tools_def.template to directly refer to AutoGen.h Liming Gao
` (5 subsequent siblings)
9 siblings, 0 replies; 27+ messages in thread
From: Liming Gao @ 2019-04-26 14:42 UTC (permalink / raw)
To: devel
LLVM/CLANG doesn't support resource section generation when ELF image generated.
Signed-off-by: Liming Gao <liming.gao@intel.com>
---
BaseTools/Conf/build_rule.template | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/BaseTools/Conf/build_rule.template b/BaseTools/Conf/build_rule.template
index 43c1b6dd3b..dec27109a1 100755
--- a/BaseTools/Conf/build_rule.template
+++ b/BaseTools/Conf/build_rule.template
@@ -636,7 +636,5 @@
"$(GENFW)" -o $(OUTPUT_DIR)(+)$(MODULE_NAME)hii.rc -g $(MODULE_GUID) --hiibinpackage $(HII_BINARY_PACKAGES) $(GENFW_FLAGS)
"$(RC)" $(RC_FLAGS) $(OUTPUT_DIR)(+)$(MODULE_NAME)hii.rc ${dst}
- <Command.XCODE, Command.RVCT>
- GenFw -o $(OUTPUT_DIR)(+)$(MODULE_NAME)hii.rc -g $(MODULE_GUID) --hiibinpackage $(HII_BINARY_PACKAGES)
-
-
+ <Command.XCODE, Command.RVCT, Command.CLANGGCC>
+ "$(GENFW)" -o $(OUTPUT_DIR)(+)$(MODULE_NAME)hii.rc -g $(MODULE_GUID) --hiibinpackage $(HII_BINARY_PACKAGES) $(GENFW_FLAGS)
--
2.13.0.windows.1
^ permalink raw reply related [flat|nested] 27+ messages in thread* [Patch 5/7] BaseTools: Update tools_def.template to directly refer to AutoGen.h
2019-04-26 14:42 [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8 Liming Gao
` (3 preceding siblings ...)
2019-04-26 14:42 ` [Patch 4/7] BaseTools: Update build_rule to skip CLANG resource section generation Liming Gao
@ 2019-04-26 14:42 ` Liming Gao
2019-04-26 14:42 ` [Patch 6/7] BaseTools: Add new CLANG8ELF tool chain for new LLVM/CLANG8 Liming Gao
` (4 subsequent siblings)
9 siblings, 0 replies; 27+ messages in thread
From: Liming Gao @ 2019-04-26 14:42 UTC (permalink / raw)
To: devel
Full path $(DEST_DIR_DEBUG)\AutoGen.h is not necessary, because
$(DEST_DIR_DEBUG) has been listed in $(INC) include paths.
Change-Id: Iadf2c7223708468b504298f0b43034c4f117ac66
Signed-off-by: Liming Gao <liming.gao@intel.com>
---
BaseTools/Conf/tools_def.template | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template
index b9e66002d0..29dc24774a 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -426,8 +426,8 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
# *_*_EBC_SLINK_PATH = C:\Program Files\Intel\EBC\Bin\link.exe
#
# *_*_EBC_SLINK_FLAGS = /lib /NOLOGO /MACHINE:EBC
-# *_*_EBC_PP_FLAGS = /nologo /E /TC /FI$(DEST_DIR_DEBUG)/AutoGen.h
-# *_*_EBC_CC_FLAGS = /nologo /FAcs /c /W3 /WX /FI$(DEST_DIR_DEBUG)/AutoGen.h
+# *_*_EBC_PP_FLAGS = /nologo /E /TC /FIAutoGen.h
+# *_*_EBC_CC_FLAGS = /nologo /FAcs /c /W3 /WX /FIAutoGen.h
# *_*_EBC_DLINK_FLAGS = "C:\Program Files\Intel\EBC\Lib\EbcLib.lib" /NOLOGO /MACHINE:EBC /OPT:REF /NODEFAULTLIB /ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /ALIGN:32 /DRIVER
#
####################################################################################
@@ -2984,13 +2984,13 @@ DEFINE GCC_IA32_X64_ASLDLINK_FLAGS = DEF(GCC_IA32_X64_DLINK_COMMON) --entry _Ref
DEFINE GCC_ARM_ASLDLINK_FLAGS = DEF(GCC_ARM_DLINK_FLAGS) -Wl,--entry,ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) DEF(GCC_ARM_AARCH64_ASLDLINK_FLAGS)
DEFINE GCC_AARCH64_ASLDLINK_FLAGS = DEF(GCC_AARCH64_DLINK_FLAGS) -Wl,--entry,ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) DEF(GCC_ARM_AARCH64_ASLDLINK_FLAGS)
DEFINE GCC_IA32_X64_DLINK_FLAGS = DEF(GCC_IA32_X64_DLINK_COMMON) --entry _$(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map
-DEFINE GCC_ASM_FLAGS = -c -x assembler -imacros $(DEST_DIR_DEBUG)/AutoGen.h
-DEFINE GCC_PP_FLAGS = -E -x assembler-with-cpp -include $(DEST_DIR_DEBUG)/AutoGen.h
-DEFINE GCC_VFRPP_FLAGS = -x c -E -P -DVFRCOMPILE --include $(DEST_DIR_DEBUG)/$(MODULE_NAME)StrDefs.h
+DEFINE GCC_ASM_FLAGS = -c -x assembler -imacros AutoGen.h
+DEFINE GCC_PP_FLAGS = -E -x assembler-with-cpp -include AutoGen.h
+DEFINE GCC_VFRPP_FLAGS = -x c -E -P -DVFRCOMPILE --include $(MODULE_NAME)StrDefs.h
DEFINE GCC_ASLPP_FLAGS = -x c -E -include AutoGen.h
DEFINE GCC_ASLCC_FLAGS = -x c
DEFINE GCC_WINDRES_FLAGS = -J rc -O coff
-DEFINE GCC_DTCPP_FLAGS = -E -x assembler-with-cpp -imacros $(DEST_DIR_DEBUG)/AutoGen.h -nostdinc -undef
+DEFINE GCC_DTCPP_FLAGS = -E -x assembler-with-cpp -imacros AutoGen.h -nostdinc -undef
DEFINE GCC_IA32_RC_FLAGS = -I binary -O elf32-i386 -B i386 --rename-section .data=.hii
DEFINE GCC_X64_RC_FLAGS = -I binary -O elf64-x86-64 -B i386 --rename-section .data=.hii
DEFINE GCC_ARM_RC_FLAGS = -I binary -O elf32-littlearm -B arm --rename-section .data=.hii
@@ -3850,8 +3850,8 @@ RELEASE_XCODE5_X64_DLINK_FLAGS = -arch x86_64 -u _$(IMAGE_ENTRY_POINT) -e _
NOOPT_XCODE5_X64_ASM_FLAGS = -arch x86_64 -g
RELEASE_XCODE5_X64_ASM_FLAGS = -arch x86_64
*_XCODE5_X64_NASM_FLAGS = -f macho64
-*_XCODE5_*_PP_FLAGS = -E -x assembler-with-cpp -include $(DEST_DIR_DEBUG)/AutoGen.h
-*_XCODE5_*_VFRPP_FLAGS = -x c -E -P -DVFRCOMPILE -include $(DEST_DIR_DEBUG)/$(MODULE_NAME)StrDefs.h
+*_XCODE5_*_PP_FLAGS = -E -x assembler-with-cpp -include AutoGen.h
+*_XCODE5_*_VFRPP_FLAGS = -x c -E -P -DVFRCOMPILE -include $(MODULE_NAME)StrDefs.h
DEBUG_XCODE5_X64_CC_FLAGS = -target x86_64-pc-win32-macho -c -g -Os -Wall -Werror -Wextra -include AutoGen.h -funsigned-char -fno-ms-extensions -fno-stack-protector -fno-builtin -fshort-wchar -mno-implicit-float -mms-bitfields -Wno-unused-parameter -Wno-missing-braces -Wno-missing-field-initializers -Wno-tautological-compare -Wno-sign-compare -Wno-varargs -ftrap-function=undefined_behavior_has_been_optimized_away_by_clang -D NO_MSABI_VA_FUNCS $(PLATFORM_FLAGS)
NOOPT_XCODE5_X64_CC_FLAGS = -target x86_64-pc-win32-macho -c -g -O0 -Wall -Werror -Wextra -include AutoGen.h -funsigned-char -fno-ms-extensions -fno-stack-protector -fno-builtin -fshort-wchar -mno-implicit-float -mms-bitfields -Wno-unused-parameter -Wno-missing-braces -Wno-missing-field-initializers -Wno-tautological-compare -Wno-sign-compare -Wno-varargs -ftrap-function=undefined_behavior_has_been_optimized_away_by_clang -D NO_MSABI_VA_FUNCS $(PLATFORM_FLAGS)
--
2.13.0.windows.1
^ permalink raw reply related [flat|nested] 27+ messages in thread* [Patch 6/7] BaseTools: Add new CLANG8ELF tool chain for new LLVM/CLANG8
2019-04-26 14:42 [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8 Liming Gao
` (4 preceding siblings ...)
2019-04-26 14:42 ` [Patch 5/7] BaseTools: Update tools_def.template to directly refer to AutoGen.h Liming Gao
@ 2019-04-26 14:42 ` Liming Gao
2019-05-17 1:16 ` [edk2-devel] " Bob Feng
2019-04-26 14:42 ` [Patch 7/7] OvmfPkg: Update DSC/FDF to support CLANG8ELF tool chain Liming Gao
` (3 subsequent siblings)
9 siblings, 1 reply; 27+ messages in thread
From: Liming Gao @ 2019-04-26 14:42 UTC (permalink / raw)
To: devel
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
For example:
set CLANG_HOST_BIN=n # use windows nmake
set CLANG8_BIN=C:\Program Files\LLVM\bin\
On Linux/Mac, set CLANG8_BIN=LLVM installed directory
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 nmake.exe.
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.
Signed-off-by: Liming Gao <liming.gao@intel.com>
---
BaseTools/Conf/tools_def.template | 105 ++++++++++++++++++++++++++++++++++++++
1 file changed, 105 insertions(+)
diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template
index 29dc24774a..3d95a3a6a2 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -255,6 +255,13 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
# Required to build platforms or ACPI tables:
# Intel(r) ACPI Compiler from
# https://acpica.org/downloads
+# CLANG8ELF -Linux,Windows,Mac- Requires:
+# LLVM 8.0.0 or above, https://llvm.org/
+# On Windows OS, Visual Studio is required to be installed for nmake and compile BaseTools C tools.
+# Optional:
+# Required to build platforms or ACPI tables:
+# Intel(r) ACPI Compiler from
+# https://acpica.org/downloads
# VS2008xASL -win32- Requires:
# Microsoft Visual Studio 2008 Team Suite
# Microsoft Windows Server 2003 Driver Development Kit (Microsoft WINDDK) version 3790.1830
@@ -3776,7 +3783,105 @@ DEFINE CLANG38_AARCH64_DLINK_FLAGS = DEF(CLANG38_AARCH64_TARGET) DEF(GCC_AARCH6
RELEASE_CLANG38_AARCH64_CC_FLAGS = DEF(CLANG38_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -flto -O3
RELEASE_CLANG38_AARCH64_DLINK_FLAGS = DEF(CLANG38_AARCH64_DLINK_FLAGS) -flto -Wl,-O3 -L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-aarch64 -Wl,-plugin-opt=-pass-through=-llto-aarch64
+####################################################################################
+#
+# Clang 8.0.0 - This configuration is used to compile under Windows, Linux, Mac to
+# produce ELF image, and convert to PE/COFF image using LLVM/CLANG 8.0 with LTO
+#
+####################################################################################
+*_CLANG8ELF_*_*_FAMILY = GCC
+*_CLANG8ELF_*_*_BUILDRULEFAMILY = CLANGGCC
+*_CLANG8ELF_*_MAKE_PATH = ENV(CLANG_HOST_BIN)make
+*_CLANG8ELF_*_*_DLL = ENV(CLANG8_DLL)
+*_CLANG8ELF_*_ASL_PATH = DEF(UNIX_IASL_BIN)
+
+*_CLANG8ELF_*_APP_FLAGS =
+*_CLANG8ELF_*_ASL_FLAGS = DEF(IASL_FLAGS)
+*_CLANG8ELF_*_ASL_OUTFLAGS = DEF(IASL_OUTFLAGS)
+
+DEFINE CLANG8ELF_IA32_PREFIX = ENV(CLANG8_BIN)
+DEFINE CLANG8ELF_X64_PREFIX = ENV(CLANG8_BIN)
+
+# LLVM/CLANG doesn't support -n link option. So, it can't share the same IA32_X64_DLINK_COMMON flag.
+# LLVM/CLANG doesn't support common page size. So, it can't share the same GccBase.lds script.
+DEFINE CLANG8ELF_IA32_X64_DLINK_COMMON = -nostdlib -Wl,-q,--gc-sections -z max-page-size=0x40
+DEFINE CLANG8ELF_DLINK2_FLAGS_COMMON = -Wl,--script=$(EDK_TOOLS_PATH)/Scripts/ClangBase.lds
+DEFINE CLANG8ELF_IA32_X64_ASLDLINK_FLAGS = DEF(CLANG8ELF_IA32_X64_DLINK_COMMON) -Wl,--defsym=PECOFF_HEADER_SIZE=0 DEF(CLANG8ELF_DLINK2_FLAGS_COMMON) -Wl,--entry,ReferenceAcpiTable -u ReferenceAcpiTable
+DEFINE CLANG8ELF_IA32_X64_DLINK_FLAGS = DEF(CLANG8ELF_IA32_X64_DLINK_COMMON) -Wl,--entry,$(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Wl,-Map,$(DEST_DIR_DEBUG)/$(BASE_NAME).map,--whole-archive
+DEFINE CLANG8ELF_IA32_DLINK2_FLAGS = -Wl,--defsym=PECOFF_HEADER_SIZE=0x220 DEF(CLANG8ELF_DLINK2_FLAGS_COMMON)
+DEFINE CLANG8ELF_X64_DLINK2_FLAGS = -Wl,--defsym=PECOFF_HEADER_SIZE=0x228 DEF(CLANG8ELF_DLINK2_FLAGS_COMMON)
+
+###########################
+# CLANG8ELF IA32 definitions
+###########################
+*_CLANG8ELF_IA32_CC_PATH = DEF(CLANG8ELF_IA32_PREFIX)clang
+*_CLANG8ELF_IA32_SLINK_PATH = DEF(CLANG8ELF_IA32_PREFIX)llvm-ar
+*_CLANG8ELF_IA32_DLINK_PATH = DEF(CLANG8ELF_IA32_PREFIX)clang
+*_CLANG8ELF_IA32_ASLDLINK_PATH = DEF(CLANG8ELF_IA32_PREFIX)clang
+*_CLANG8ELF_IA32_ASM_PATH = DEF(CLANG8ELF_IA32_PREFIX)clang
+*_CLANG8ELF_IA32_PP_PATH = DEF(CLANG8ELF_IA32_PREFIX)clang
+*_CLANG8ELF_IA32_VFRPP_PATH = DEF(CLANG8ELF_IA32_PREFIX)clang
+*_CLANG8ELF_IA32_ASLCC_PATH = DEF(CLANG8ELF_IA32_PREFIX)clang
+*_CLANG8ELF_IA32_ASLPP_PATH = DEF(CLANG8ELF_IA32_PREFIX)clang
+*_CLANG8ELF_IA32_RC_PATH = DEF(CLANG8ELF_IA32_PREFIX)llvm-rc
+
+*_CLANG8ELF_IA32_ASLCC_FLAGS = DEF(GCC_ASLCC_FLAGS) -m32 -fno-lto DEF(CLANG38_IA32_TARGET)
+*_CLANG8ELF_IA32_ASLDLINK_FLAGS = DEF(CLANG8ELF_IA32_X64_ASLDLINK_FLAGS) -Wl,-m,elf_i386 -fuse-ld=lld
+*_CLANG8ELF_IA32_ASM_FLAGS = DEF(GCC5_ASM_FLAGS) -m32 -march=i386 DEF(CLANG38_IA32_TARGET)
+*_CLANG8ELF_IA32_RC_FLAGS = DEF(GCC_IA32_RC_FLAGS)
+*_CLANG8ELF_IA32_OBJCOPY_FLAGS =
+*_CLANG8ELF_IA32_NASM_FLAGS = -f elf32
+*_CLANG8ELF_IA32_PP_FLAGS = DEF(GCC_PP_FLAGS) DEF(CLANG38_IA32_TARGET)
+*_CLANG8ELF_IA32_ASLPP_FLAGS = DEF(GCC_ASLPP_FLAGS) DEF(CLANG38_IA32_TARGET)
+*_CLANG8ELF_IA32_VFRPP_FLAGS = DEF(GCC_VFRPP_FLAGS) DEF(CLANG38_IA32_TARGET)
+
+DEBUG_CLANG8ELF_IA32_CC_FLAGS = DEF(CLANG38_ALL_CC_FLAGS) -m32 -Oz -flto -march=i586 DEF(CLANG38_IA32_TARGET) -g
+DEBUG_CLANG8ELF_IA32_DLINK_FLAGS = DEF(CLANG8ELF_IA32_X64_DLINK_FLAGS) -flto -Wl,-O3 -Wl,-melf_i386 -Wl,--oformat,elf32-i386
+DEBUG_CLANG8ELF_IA32_DLINK2_FLAGS = DEF(CLANG8ELF_IA32_DLINK2_FLAGS) -O3 -fuse-ld=lld
+
+RELEASE_CLANG8ELF_IA32_CC_FLAGS = DEF(CLANG38_ALL_CC_FLAGS) -m32 -Oz -flto -march=i586 DEF(CLANG38_IA32_TARGET)
+RELEASE_CLANG8ELF_IA32_DLINK_FLAGS = DEF(CLANG8ELF_IA32_X64_DLINK_FLAGS) -flto -Wl,-O3 -Wl,-melf_i386 -Wl,--oformat,elf32-i386
+RELEASE_CLANG8ELF_IA32_DLINK2_FLAGS = DEF(CLANG8ELF_IA32_DLINK2_FLAGS) -O3 -fuse-ld=lld
+
+NOOPT_CLANG8ELF_IA32_CC_FLAGS = DEF(CLANG38_ALL_CC_FLAGS) -m32 -O0 -march=i586 DEF(CLANG38_IA32_TARGET) -g
+NOOPT_CLANG8ELF_IA32_DLINK_FLAGS = DEF(CLANG8ELF_IA32_X64_DLINK_FLAGS) -Wl,-O0 -Wl,-melf_i386 -Wl,--oformat,elf32-i386
+NOOPT_CLANG8ELF_IA32_DLINK2_FLAGS = DEF(CLANG8ELF_IA32_DLINK2_FLAGS) -O0 -fuse-ld=lld
+##########################
+# CLANG8ELF X64 definitions
+##########################
+*_CLANG8ELF_X64_CC_PATH = DEF(CLANG8ELF_X64_PREFIX)clang
+*_CLANG8ELF_X64_SLINK_PATH = DEF(CLANG8ELF_X64_PREFIX)llvm-ar
+*_CLANG8ELF_X64_DLINK_PATH = DEF(CLANG8ELF_X64_PREFIX)clang
+*_CLANG8ELF_X64_ASLDLINK_PATH = DEF(CLANG8ELF_X64_PREFIX)clang
+*_CLANG8ELF_X64_ASM_PATH = DEF(CLANG8ELF_X64_PREFIX)clang
+*_CLANG8ELF_X64_PP_PATH = DEF(CLANG8ELF_X64_PREFIX)clang
+*_CLANG8ELF_X64_VFRPP_PATH = DEF(CLANG8ELF_X64_PREFIX)clang
+*_CLANG8ELF_X64_ASLCC_PATH = DEF(CLANG8ELF_X64_PREFIX)clang
+*_CLANG8ELF_X64_ASLPP_PATH = DEF(CLANG8ELF_X64_PREFIX)clang
+*_CLANG8ELF_X64_RC_PATH = DEF(CLANG8ELF_X64_PREFIX)llvm-rc
+
+*_CLANG8ELF_X64_ASLCC_FLAGS = DEF(GCC_ASLCC_FLAGS) -m64 -fno-lto DEF(CLANG38_X64_TARGET)
+*_CLANG8ELF_X64_ASLDLINK_FLAGS = DEF(CLANG8ELF_IA32_X64_ASLDLINK_FLAGS) -Wl,-m,elf_x86_64 -fuse-ld=lld
+*_CLANG8ELF_X64_ASM_FLAGS = DEF(GCC5_ASM_FLAGS) -m64 DEF(CLANG38_X64_TARGET)
+*_CLANG8ELF_X64_RC_FLAGS = DEF(GCC_X64_RC_FLAGS)
+*_CLANG8ELF_X64_OBJCOPY_FLAGS =
+*_CLANG8ELF_X64_NASM_FLAGS = -f elf64
+*_CLANG8ELF_X64_PP_FLAGS = DEF(GCC_PP_FLAGS) DEF(CLANG38_X64_TARGET)
+*_CLANG8ELF_X64_ASLPP_FLAGS = DEF(GCC_ASLPP_FLAGS) DEF(CLANG38_X64_TARGET)
+*_CLANG8ELF_X64_VFRPP_FLAGS = DEF(GCC_VFRPP_FLAGS) DEF(CLANG38_X64_TARGET)
+
+DEBUG_CLANG8ELF_X64_CC_FLAGS = DEF(CLANG38_ALL_CC_FLAGS) -m64 "-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone -mcmodel=small -fpie -Oz -flto DEF(CLANG38_X64_TARGET) -g
+DEBUG_CLANG8ELF_X64_DLINK_FLAGS = DEF(CLANG8ELF_IA32_X64_DLINK_FLAGS) -flto -Wl,-O3 -Wl,-melf_x86_64 -Wl,--oformat,elf64-x86-64 -Wl,-pie -mcmodel=small -Wl,--apply-dynamic-relocs
+DEBUG_CLANG8ELF_X64_DLINK2_FLAGS = DEF(CLANG8ELF_X64_DLINK2_FLAGS) -O3 -fuse-ld=lld
+
+RELEASE_CLANG8ELF_X64_CC_FLAGS = DEF(CLANG38_ALL_CC_FLAGS) -m64 "-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone -mcmodel=small -fpie -Oz -flto DEF(CLANG38_X64_TARGET)
+RELEASE_CLANG8ELF_X64_DLINK_FLAGS = DEF(CLANG8ELF_IA32_X64_DLINK_FLAGS) -flto -Wl,-O3 -Wl,-melf_x86_64 -Wl,--oformat,elf64-x86-64 -Wl,-pie -mcmodel=small -Wl,--apply-dynamic-relocs
+RELEASE_CLANG8ELF_X64_DLINK2_FLAGS = DEF(CLANG8ELF_X64_DLINK2_FLAGS) -O3 -fuse-ld=lld
+
+NOOPT_CLANG8ELF_X64_CC_FLAGS = DEF(CLANG38_ALL_CC_FLAGS) -m64 "-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone -mcmodel=small -fpie -O0 DEF(CLANG38_X64_TARGET) -g
+NOOPT_CLANG8ELF_X64_DLINK_FLAGS = DEF(CLANG8ELF_IA32_X64_DLINK_FLAGS) -Wl,-O0 -Wl,-melf_x86_64 -Wl,--oformat,elf64-x86-64 -Wl,-pie -mcmodel=small -Wl,--apply-dynamic-relocs
+NOOPT_CLANG8ELF_X64_DLINK2_FLAGS = DEF(CLANG8ELF_X64_DLINK2_FLAGS) -O0 -fuse-ld=lld
#
#
--
2.13.0.windows.1
^ permalink raw reply related [flat|nested] 27+ messages in thread* Re: [edk2-devel] [Patch 6/7] BaseTools: Add new CLANG8ELF tool chain for new LLVM/CLANG8
2019-04-26 14:42 ` [Patch 6/7] BaseTools: Add new CLANG8ELF tool chain for new LLVM/CLANG8 Liming Gao
@ 2019-05-17 1:16 ` Bob Feng
0 siblings, 0 replies; 27+ messages in thread
From: Bob Feng @ 2019-05-17 1:16 UTC (permalink / raw)
To: devel@edk2.groups.io, Gao, Liming
The Basetools patch is good for me.
For this single patch,
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
-----Original Message-----
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Liming Gao
Sent: Friday, April 26, 2019 10:43 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] [Patch 6/7] BaseTools: Add new CLANG8ELF tool chain for new LLVM/CLANG8
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 For example:
set CLANG_HOST_BIN=n # use windows nmake
set CLANG8_BIN=C:\Program Files\LLVM\bin\ On Linux/Mac, set CLANG8_BIN=LLVM installed directory
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 nmake.exe.
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.
Signed-off-by: Liming Gao <liming.gao@intel.com>
---
BaseTools/Conf/tools_def.template | 105 ++++++++++++++++++++++++++++++++++++++
1 file changed, 105 insertions(+)
diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template
index 29dc24774a..3d95a3a6a2 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -255,6 +255,13 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
# Required to build platforms or ACPI tables:
# Intel(r) ACPI Compiler from
# https://acpica.org/downloads
+# CLANG8ELF -Linux,Windows,Mac- Requires:
+# LLVM 8.0.0 or above, https://llvm.org/
+# On Windows OS, Visual Studio is required to be installed for nmake and compile BaseTools C tools.
+# Optional:
+# Required to build platforms or ACPI tables:
+# Intel(r) ACPI Compiler from
+# https://acpica.org/downloads
# VS2008xASL -win32- Requires:
# Microsoft Visual Studio 2008 Team Suite
# Microsoft Windows Server 2003 Driver Development Kit (Microsoft WINDDK) version 3790.1830
@@ -3776,7 +3783,105 @@ DEFINE CLANG38_AARCH64_DLINK_FLAGS = DEF(CLANG38_AARCH64_TARGET) DEF(GCC_AARCH6
RELEASE_CLANG38_AARCH64_CC_FLAGS = DEF(CLANG38_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -flto -O3
RELEASE_CLANG38_AARCH64_DLINK_FLAGS = DEF(CLANG38_AARCH64_DLINK_FLAGS) -flto -Wl,-O3 -L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-aarch64 -Wl,-plugin-opt=-pass-through=-llto-aarch64
+#######################################################################
+#############
+#
+# Clang 8.0.0 - This configuration is used to compile under Windows,
+Linux, Mac to # produce ELF image, and convert to PE/COFF image using
+LLVM/CLANG 8.0 with LTO #
+####################################################################################
+*_CLANG8ELF_*_*_FAMILY = GCC
+*_CLANG8ELF_*_*_BUILDRULEFAMILY = CLANGGCC
+*_CLANG8ELF_*_MAKE_PATH = ENV(CLANG_HOST_BIN)make
+*_CLANG8ELF_*_*_DLL = ENV(CLANG8_DLL)
+*_CLANG8ELF_*_ASL_PATH = DEF(UNIX_IASL_BIN)
+
+*_CLANG8ELF_*_APP_FLAGS =
+*_CLANG8ELF_*_ASL_FLAGS = DEF(IASL_FLAGS)
+*_CLANG8ELF_*_ASL_OUTFLAGS = DEF(IASL_OUTFLAGS)
+
+DEFINE CLANG8ELF_IA32_PREFIX = ENV(CLANG8_BIN)
+DEFINE CLANG8ELF_X64_PREFIX = ENV(CLANG8_BIN)
+
+# LLVM/CLANG doesn't support -n link option. So, it can't share the same IA32_X64_DLINK_COMMON flag.
+# LLVM/CLANG doesn't support common page size. So, it can't share the same GccBase.lds script.
+DEFINE CLANG8ELF_IA32_X64_DLINK_COMMON = -nostdlib -Wl,-q,--gc-sections -z max-page-size=0x40
+DEFINE CLANG8ELF_DLINK2_FLAGS_COMMON = -Wl,--script=$(EDK_TOOLS_PATH)/Scripts/ClangBase.lds
+DEFINE CLANG8ELF_IA32_X64_ASLDLINK_FLAGS = DEF(CLANG8ELF_IA32_X64_DLINK_COMMON) -Wl,--defsym=PECOFF_HEADER_SIZE=0 DEF(CLANG8ELF_DLINK2_FLAGS_COMMON) -Wl,--entry,ReferenceAcpiTable -u ReferenceAcpiTable
+DEFINE CLANG8ELF_IA32_X64_DLINK_FLAGS = DEF(CLANG8ELF_IA32_X64_DLINK_COMMON) -Wl,--entry,$(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Wl,-Map,$(DEST_DIR_DEBUG)/$(BASE_NAME).map,--whole-archive
+DEFINE CLANG8ELF_IA32_DLINK2_FLAGS = -Wl,--defsym=PECOFF_HEADER_SIZE=0x220 DEF(CLANG8ELF_DLINK2_FLAGS_COMMON)
+DEFINE CLANG8ELF_X64_DLINK2_FLAGS = -Wl,--defsym=PECOFF_HEADER_SIZE=0x228 DEF(CLANG8ELF_DLINK2_FLAGS_COMMON)
+
+###########################
+# CLANG8ELF IA32 definitions
+###########################
+*_CLANG8ELF_IA32_CC_PATH = DEF(CLANG8ELF_IA32_PREFIX)clang
+*_CLANG8ELF_IA32_SLINK_PATH = DEF(CLANG8ELF_IA32_PREFIX)llvm-ar
+*_CLANG8ELF_IA32_DLINK_PATH = DEF(CLANG8ELF_IA32_PREFIX)clang
+*_CLANG8ELF_IA32_ASLDLINK_PATH = DEF(CLANG8ELF_IA32_PREFIX)clang
+*_CLANG8ELF_IA32_ASM_PATH = DEF(CLANG8ELF_IA32_PREFIX)clang
+*_CLANG8ELF_IA32_PP_PATH = DEF(CLANG8ELF_IA32_PREFIX)clang
+*_CLANG8ELF_IA32_VFRPP_PATH = DEF(CLANG8ELF_IA32_PREFIX)clang
+*_CLANG8ELF_IA32_ASLCC_PATH = DEF(CLANG8ELF_IA32_PREFIX)clang
+*_CLANG8ELF_IA32_ASLPP_PATH = DEF(CLANG8ELF_IA32_PREFIX)clang
+*_CLANG8ELF_IA32_RC_PATH = DEF(CLANG8ELF_IA32_PREFIX)llvm-rc
+
+*_CLANG8ELF_IA32_ASLCC_FLAGS = DEF(GCC_ASLCC_FLAGS) -m32 -fno-lto DEF(CLANG38_IA32_TARGET)
+*_CLANG8ELF_IA32_ASLDLINK_FLAGS = DEF(CLANG8ELF_IA32_X64_ASLDLINK_FLAGS) -Wl,-m,elf_i386 -fuse-ld=lld
+*_CLANG8ELF_IA32_ASM_FLAGS = DEF(GCC5_ASM_FLAGS) -m32 -march=i386 DEF(CLANG38_IA32_TARGET)
+*_CLANG8ELF_IA32_RC_FLAGS = DEF(GCC_IA32_RC_FLAGS)
+*_CLANG8ELF_IA32_OBJCOPY_FLAGS =
+*_CLANG8ELF_IA32_NASM_FLAGS = -f elf32
+*_CLANG8ELF_IA32_PP_FLAGS = DEF(GCC_PP_FLAGS) DEF(CLANG38_IA32_TARGET)
+*_CLANG8ELF_IA32_ASLPP_FLAGS = DEF(GCC_ASLPP_FLAGS) DEF(CLANG38_IA32_TARGET)
+*_CLANG8ELF_IA32_VFRPP_FLAGS = DEF(GCC_VFRPP_FLAGS) DEF(CLANG38_IA32_TARGET)
+
+DEBUG_CLANG8ELF_IA32_CC_FLAGS = DEF(CLANG38_ALL_CC_FLAGS) -m32 -Oz -flto -march=i586 DEF(CLANG38_IA32_TARGET) -g
+DEBUG_CLANG8ELF_IA32_DLINK_FLAGS = DEF(CLANG8ELF_IA32_X64_DLINK_FLAGS) -flto -Wl,-O3 -Wl,-melf_i386 -Wl,--oformat,elf32-i386
+DEBUG_CLANG8ELF_IA32_DLINK2_FLAGS = DEF(CLANG8ELF_IA32_DLINK2_FLAGS) -O3 -fuse-ld=lld
+
+RELEASE_CLANG8ELF_IA32_CC_FLAGS = DEF(CLANG38_ALL_CC_FLAGS) -m32 -Oz -flto -march=i586 DEF(CLANG38_IA32_TARGET)
+RELEASE_CLANG8ELF_IA32_DLINK_FLAGS = DEF(CLANG8ELF_IA32_X64_DLINK_FLAGS) -flto -Wl,-O3 -Wl,-melf_i386 -Wl,--oformat,elf32-i386
+RELEASE_CLANG8ELF_IA32_DLINK2_FLAGS = DEF(CLANG8ELF_IA32_DLINK2_FLAGS) -O3 -fuse-ld=lld
+
+NOOPT_CLANG8ELF_IA32_CC_FLAGS = DEF(CLANG38_ALL_CC_FLAGS) -m32 -O0 -march=i586 DEF(CLANG38_IA32_TARGET) -g
+NOOPT_CLANG8ELF_IA32_DLINK_FLAGS = DEF(CLANG8ELF_IA32_X64_DLINK_FLAGS) -Wl,-O0 -Wl,-melf_i386 -Wl,--oformat,elf32-i386
+NOOPT_CLANG8ELF_IA32_DLINK2_FLAGS = DEF(CLANG8ELF_IA32_DLINK2_FLAGS) -O0 -fuse-ld=lld
+##########################
+# CLANG8ELF X64 definitions
+##########################
+*_CLANG8ELF_X64_CC_PATH = DEF(CLANG8ELF_X64_PREFIX)clang
+*_CLANG8ELF_X64_SLINK_PATH = DEF(CLANG8ELF_X64_PREFIX)llvm-ar
+*_CLANG8ELF_X64_DLINK_PATH = DEF(CLANG8ELF_X64_PREFIX)clang
+*_CLANG8ELF_X64_ASLDLINK_PATH = DEF(CLANG8ELF_X64_PREFIX)clang
+*_CLANG8ELF_X64_ASM_PATH = DEF(CLANG8ELF_X64_PREFIX)clang
+*_CLANG8ELF_X64_PP_PATH = DEF(CLANG8ELF_X64_PREFIX)clang
+*_CLANG8ELF_X64_VFRPP_PATH = DEF(CLANG8ELF_X64_PREFIX)clang
+*_CLANG8ELF_X64_ASLCC_PATH = DEF(CLANG8ELF_X64_PREFIX)clang
+*_CLANG8ELF_X64_ASLPP_PATH = DEF(CLANG8ELF_X64_PREFIX)clang
+*_CLANG8ELF_X64_RC_PATH = DEF(CLANG8ELF_X64_PREFIX)llvm-rc
+
+*_CLANG8ELF_X64_ASLCC_FLAGS = DEF(GCC_ASLCC_FLAGS) -m64 -fno-lto DEF(CLANG38_X64_TARGET)
+*_CLANG8ELF_X64_ASLDLINK_FLAGS = DEF(CLANG8ELF_IA32_X64_ASLDLINK_FLAGS) -Wl,-m,elf_x86_64 -fuse-ld=lld
+*_CLANG8ELF_X64_ASM_FLAGS = DEF(GCC5_ASM_FLAGS) -m64 DEF(CLANG38_X64_TARGET)
+*_CLANG8ELF_X64_RC_FLAGS = DEF(GCC_X64_RC_FLAGS)
+*_CLANG8ELF_X64_OBJCOPY_FLAGS =
+*_CLANG8ELF_X64_NASM_FLAGS = -f elf64
+*_CLANG8ELF_X64_PP_FLAGS = DEF(GCC_PP_FLAGS) DEF(CLANG38_X64_TARGET)
+*_CLANG8ELF_X64_ASLPP_FLAGS = DEF(GCC_ASLPP_FLAGS) DEF(CLANG38_X64_TARGET)
+*_CLANG8ELF_X64_VFRPP_FLAGS = DEF(GCC_VFRPP_FLAGS) DEF(CLANG38_X64_TARGET)
+
+DEBUG_CLANG8ELF_X64_CC_FLAGS = DEF(CLANG38_ALL_CC_FLAGS) -m64 "-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone -mcmodel=small -fpie -Oz -flto DEF(CLANG38_X64_TARGET) -g
+DEBUG_CLANG8ELF_X64_DLINK_FLAGS = DEF(CLANG8ELF_IA32_X64_DLINK_FLAGS) -flto -Wl,-O3 -Wl,-melf_x86_64 -Wl,--oformat,elf64-x86-64 -Wl,-pie -mcmodel=small -Wl,--apply-dynamic-relocs
+DEBUG_CLANG8ELF_X64_DLINK2_FLAGS = DEF(CLANG8ELF_X64_DLINK2_FLAGS) -O3 -fuse-ld=lld
+
+RELEASE_CLANG8ELF_X64_CC_FLAGS = DEF(CLANG38_ALL_CC_FLAGS) -m64 "-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone -mcmodel=small -fpie -Oz -flto DEF(CLANG38_X64_TARGET)
+RELEASE_CLANG8ELF_X64_DLINK_FLAGS = DEF(CLANG8ELF_IA32_X64_DLINK_FLAGS) -flto -Wl,-O3 -Wl,-melf_x86_64 -Wl,--oformat,elf64-x86-64 -Wl,-pie -mcmodel=small -Wl,--apply-dynamic-relocs
+RELEASE_CLANG8ELF_X64_DLINK2_FLAGS = DEF(CLANG8ELF_X64_DLINK2_FLAGS) -O3 -fuse-ld=lld
+
+NOOPT_CLANG8ELF_X64_CC_FLAGS = DEF(CLANG38_ALL_CC_FLAGS) -m64 "-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone -mcmodel=small -fpie -O0 DEF(CLANG38_X64_TARGET) -g
+NOOPT_CLANG8ELF_X64_DLINK_FLAGS = DEF(CLANG8ELF_IA32_X64_DLINK_FLAGS) -Wl,-O0 -Wl,-melf_x86_64 -Wl,--oformat,elf64-x86-64 -Wl,-pie -mcmodel=small -Wl,--apply-dynamic-relocs
+NOOPT_CLANG8ELF_X64_DLINK2_FLAGS = DEF(CLANG8ELF_X64_DLINK2_FLAGS) -O0 -fuse-ld=lld
#
#
--
2.13.0.windows.1
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [Patch 7/7] OvmfPkg: Update DSC/FDF to support CLANG8ELF tool chain
2019-04-26 14:42 [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8 Liming Gao
` (5 preceding siblings ...)
2019-04-26 14:42 ` [Patch 6/7] BaseTools: Add new CLANG8ELF tool chain for new LLVM/CLANG8 Liming Gao
@ 2019-04-26 14:42 ` Liming Gao
2019-05-19 13:24 ` [edk2-devel] " Ard Biesheuvel
2019-05-20 14:33 ` Laszlo Ersek
2019-04-26 16:33 ` [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8 Ard Biesheuvel
` (2 subsequent siblings)
9 siblings, 2 replies; 27+ messages in thread
From: Liming Gao @ 2019-04-26 14:42 UTC (permalink / raw)
To: devel
Signed-off-by: Liming Gao <liming.gao@intel.com>
---
OvmfPkg/OvmfPkgIa32.dsc | 4 +++-
OvmfPkg/OvmfPkgIa32.fdf | 2 +-
OvmfPkg/OvmfPkgIa32X64.dsc | 4 +++-
OvmfPkg/OvmfPkgIa32X64.fdf | 2 +-
OvmfPkg/OvmfPkgX64.dsc | 4 +++-
OvmfPkg/OvmfPkgX64.fdf | 2 +-
6 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 98a8467e86..7972b25112 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -73,12 +73,14 @@
[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
+ CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
XCODE:*_*_*_DLINK_FLAGS =
# Force PE/COFF sections to be aligned at 4KB boundaries to support page level
# protection of DXE_SMM_DRIVER/SMM_CORE modules
[BuildOptions.common.EDKII.DXE_SMM_DRIVER, BuildOptions.common.EDKII.SMM_CORE]
GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
+ CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
XCODE:*_*_*_DLINK_FLAGS =
################################################################################
@@ -832,7 +834,7 @@
OvmfPkg/Csm/Csm16/Csm16.inf
!endif
-!if $(TOOL_CHAIN_TAG) != "XCODE5"
+!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
<PcdsFixedAtBuild>
gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index bc08bf2243..2894cfe8d6 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -287,7 +287,7 @@ INF MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResour
INF FatPkg/EnhancedFatDxe/Fat.inf
INF MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
-!if $(TOOL_CHAIN_TAG) != "XCODE5"
+!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
INF ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
!endif
INF ShellPkg/Application/Shell/Shell.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 1f722fc987..c9feeafaae 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -78,12 +78,14 @@
[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
+ CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
XCODE:*_*_*_DLINK_FLAGS =
# Force PE/COFF sections to be aligned at 4KB boundaries to support page level
# protection of DXE_SMM_DRIVER/SMM_CORE modules
[BuildOptions.common.EDKII.DXE_SMM_DRIVER, BuildOptions.common.EDKII.SMM_CORE]
GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
+ CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
XCODE:*_*_*_DLINK_FLAGS =
################################################################################
@@ -841,7 +843,7 @@
OvmfPkg/Csm/Csm16/Csm16.inf
!endif
-!if $(TOOL_CHAIN_TAG) != "XCODE5"
+!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
<PcdsFixedAtBuild>
gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index ccf36c5dd9..affce983f9 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -288,7 +288,7 @@ INF MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResour
INF FatPkg/EnhancedFatDxe/Fat.inf
INF MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
-!if $(TOOL_CHAIN_TAG) != "XCODE5"
+!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
INF ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
!endif
INF ShellPkg/Application/Shell/Shell.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 2927ee07b8..f28ec13c0c 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -78,12 +78,14 @@
[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
+ CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
XCODE:*_*_*_DLINK_FLAGS =
# Force PE/COFF sections to be aligned at 4KB boundaries to support page level
# protection of DXE_SMM_DRIVER/SMM_CORE modules
[BuildOptions.common.EDKII.DXE_SMM_DRIVER, BuildOptions.common.EDKII.SMM_CORE]
GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
+ CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
XCODE:*_*_*_DLINK_FLAGS =
################################################################################
@@ -839,7 +841,7 @@
OvmfPkg/Csm/Csm16/Csm16.inf
!endif
-!if $(TOOL_CHAIN_TAG) != "XCODE5"
+!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
<PcdsFixedAtBuild>
gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index ccf36c5dd9..affce983f9 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -288,7 +288,7 @@ INF MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResour
INF FatPkg/EnhancedFatDxe/Fat.inf
INF MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
-!if $(TOOL_CHAIN_TAG) != "XCODE5"
+!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
INF ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
!endif
INF ShellPkg/Application/Shell/Shell.inf
--
2.13.0.windows.1
^ permalink raw reply related [flat|nested] 27+ messages in thread* Re: [edk2-devel] [Patch 7/7] OvmfPkg: Update DSC/FDF to support CLANG8ELF tool chain
2019-04-26 14:42 ` [Patch 7/7] OvmfPkg: Update DSC/FDF to support CLANG8ELF tool chain Liming Gao
@ 2019-05-19 13:24 ` Ard Biesheuvel
2019-05-19 13:45 ` Liming Gao
2019-05-20 14:33 ` Laszlo Ersek
1 sibling, 1 reply; 27+ messages in thread
From: Ard Biesheuvel @ 2019-05-19 13:24 UTC (permalink / raw)
To: edk2-devel-groups-io, Gao, Liming
On Fri, 26 Apr 2019 at 16:43, Liming Gao <liming.gao@intel.com> wrote:
>
> Signed-off-by: Liming Gao <liming.gao@intel.com>
> ---
> OvmfPkg/OvmfPkgIa32.dsc | 4 +++-
> OvmfPkg/OvmfPkgIa32.fdf | 2 +-
> OvmfPkg/OvmfPkgIa32X64.dsc | 4 +++-
> OvmfPkg/OvmfPkgIa32X64.fdf | 2 +-
> OvmfPkg/OvmfPkgX64.dsc | 4 +++-
> OvmfPkg/OvmfPkgX64.fdf | 2 +-
> 6 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 98a8467e86..7972b25112 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -73,12 +73,14 @@
>
> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> + CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
So are we introducing a new toolchain family just for the linker
flags? In that case, it would be better to call the toolchain family
CLANGLLD or LLVMLLD.
We could also consider switching all GNU ld toolchains to use
max-page-size instead of common-page-size, given that binutils
supports both.
> XCODE:*_*_*_DLINK_FLAGS =
>
> # Force PE/COFF sections to be aligned at 4KB boundaries to support page level
> # protection of DXE_SMM_DRIVER/SMM_CORE modules
> [BuildOptions.common.EDKII.DXE_SMM_DRIVER, BuildOptions.common.EDKII.SMM_CORE]
> GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> + CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
> XCODE:*_*_*_DLINK_FLAGS =
>
> ################################################################################
> @@ -832,7 +834,7 @@
> OvmfPkg/Csm/Csm16/Csm16.inf
> !endif
>
> -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
> ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
> <PcdsFixedAtBuild>
> gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
> index bc08bf2243..2894cfe8d6 100644
> --- a/OvmfPkg/OvmfPkgIa32.fdf
> +++ b/OvmfPkg/OvmfPkgIa32.fdf
> @@ -287,7 +287,7 @@ INF MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResour
> INF FatPkg/EnhancedFatDxe/Fat.inf
> INF MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
>
> -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
> INF ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
> !endif
> INF ShellPkg/Application/Shell/Shell.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 1f722fc987..c9feeafaae 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -78,12 +78,14 @@
>
> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> + CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
> XCODE:*_*_*_DLINK_FLAGS =
>
> # Force PE/COFF sections to be aligned at 4KB boundaries to support page level
> # protection of DXE_SMM_DRIVER/SMM_CORE modules
> [BuildOptions.common.EDKII.DXE_SMM_DRIVER, BuildOptions.common.EDKII.SMM_CORE]
> GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> + CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
> XCODE:*_*_*_DLINK_FLAGS =
>
> ################################################################################
> @@ -841,7 +843,7 @@
> OvmfPkg/Csm/Csm16/Csm16.inf
> !endif
>
> -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
> ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
> <PcdsFixedAtBuild>
> gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
> index ccf36c5dd9..affce983f9 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.fdf
> +++ b/OvmfPkg/OvmfPkgIa32X64.fdf
> @@ -288,7 +288,7 @@ INF MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResour
> INF FatPkg/EnhancedFatDxe/Fat.inf
> INF MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
>
> -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
> INF ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
> !endif
> INF ShellPkg/Application/Shell/Shell.inf
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 2927ee07b8..f28ec13c0c 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -78,12 +78,14 @@
>
> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> + CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
> XCODE:*_*_*_DLINK_FLAGS =
>
> # Force PE/COFF sections to be aligned at 4KB boundaries to support page level
> # protection of DXE_SMM_DRIVER/SMM_CORE modules
> [BuildOptions.common.EDKII.DXE_SMM_DRIVER, BuildOptions.common.EDKII.SMM_CORE]
> GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> + CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
> XCODE:*_*_*_DLINK_FLAGS =
>
> ################################################################################
> @@ -839,7 +841,7 @@
> OvmfPkg/Csm/Csm16/Csm16.inf
> !endif
>
> -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
> ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
> <PcdsFixedAtBuild>
> gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
> index ccf36c5dd9..affce983f9 100644
> --- a/OvmfPkg/OvmfPkgX64.fdf
> +++ b/OvmfPkg/OvmfPkgX64.fdf
> @@ -288,7 +288,7 @@ INF MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResour
> INF FatPkg/EnhancedFatDxe/Fat.inf
> INF MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
>
> -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
> INF ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
> !endif
> INF ShellPkg/Application/Shell/Shell.inf
> --
> 2.13.0.windows.1
>
>
>
>
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: [edk2-devel] [Patch 7/7] OvmfPkg: Update DSC/FDF to support CLANG8ELF tool chain
2019-05-19 13:24 ` [edk2-devel] " Ard Biesheuvel
@ 2019-05-19 13:45 ` Liming Gao
0 siblings, 0 replies; 27+ messages in thread
From: Liming Gao @ 2019-05-19 13:45 UTC (permalink / raw)
To: Ard Biesheuvel, edk2-devel-groups-io
Ard:
> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> Sent: Sunday, May 19, 2019 9:24 PM
> To: edk2-devel-groups-io <devel@edk2.groups.io>; Gao, Liming <liming.gao@intel.com>
> Subject: Re: [edk2-devel] [Patch 7/7] OvmfPkg: Update DSC/FDF to support CLANG8ELF tool chain
>
> On Fri, 26 Apr 2019 at 16:43, Liming Gao <liming.gao@intel.com> wrote:
> >
> > Signed-off-by: Liming Gao <liming.gao@intel.com>
> > ---
> > OvmfPkg/OvmfPkgIa32.dsc | 4 +++-
> > OvmfPkg/OvmfPkgIa32.fdf | 2 +-
> > OvmfPkg/OvmfPkgIa32X64.dsc | 4 +++-
> > OvmfPkg/OvmfPkgIa32X64.fdf | 2 +-
> > OvmfPkg/OvmfPkgX64.dsc | 4 +++-
> > OvmfPkg/OvmfPkgX64.fdf | 2 +-
> > 6 files changed, 12 insertions(+), 6 deletions(-)
> >
> > diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> > index 98a8467e86..7972b25112 100644
> > --- a/OvmfPkg/OvmfPkgIa32.dsc
> > +++ b/OvmfPkg/OvmfPkgIa32.dsc
> > @@ -73,12 +73,14 @@
> >
> > [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> > GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> > + CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
>
> So are we introducing a new toolchain family just for the linker
> flags? In that case, it would be better to call the toolchain family
> CLANGLLD or LLVMLLD.
This is the tool chain BUILDRULEFAMILY, not tool chain family. It is for the build rule customization.
I agree CLANGLLD is better.
>
> We could also consider switching all GNU ld toolchains to use
> max-page-size instead of common-page-size, given that binutils
> supports both.
>
Yes. Binutils supports max-page-size option also. But, I don't investigate more on
common-page-size and max-page-size in Binutils. To not impact GCC tool chain,
I enable max-page-size option first in CLANGLLD tool chain, because CLANG LLD only supports it.
> > XCODE:*_*_*_DLINK_FLAGS =
> >
> > # Force PE/COFF sections to be aligned at 4KB boundaries to support page level
> > # protection of DXE_SMM_DRIVER/SMM_CORE modules
> > [BuildOptions.common.EDKII.DXE_SMM_DRIVER, BuildOptions.common.EDKII.SMM_CORE]
> > GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> > + CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
> > XCODE:*_*_*_DLINK_FLAGS =
> >
> > ################################################################################
> > @@ -832,7 +834,7 @@
> > OvmfPkg/Csm/Csm16/Csm16.inf
> > !endif
> >
> > -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> > +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
> > ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
> > <PcdsFixedAtBuild>
> > gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> > diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
> > index bc08bf2243..2894cfe8d6 100644
> > --- a/OvmfPkg/OvmfPkgIa32.fdf
> > +++ b/OvmfPkg/OvmfPkgIa32.fdf
> > @@ -287,7 +287,7 @@ INF MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResour
> > INF FatPkg/EnhancedFatDxe/Fat.inf
> > INF MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
> >
> > -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> > +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
> > INF ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
> > !endif
> > INF ShellPkg/Application/Shell/Shell.inf
> > diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> > index 1f722fc987..c9feeafaae 100644
> > --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> > +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> > @@ -78,12 +78,14 @@
> >
> > [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> > GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> > + CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
> > XCODE:*_*_*_DLINK_FLAGS =
> >
> > # Force PE/COFF sections to be aligned at 4KB boundaries to support page level
> > # protection of DXE_SMM_DRIVER/SMM_CORE modules
> > [BuildOptions.common.EDKII.DXE_SMM_DRIVER, BuildOptions.common.EDKII.SMM_CORE]
> > GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> > + CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
> > XCODE:*_*_*_DLINK_FLAGS =
> >
> > ################################################################################
> > @@ -841,7 +843,7 @@
> > OvmfPkg/Csm/Csm16/Csm16.inf
> > !endif
> >
> > -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> > +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
> > ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
> > <PcdsFixedAtBuild>
> > gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> > diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
> > index ccf36c5dd9..affce983f9 100644
> > --- a/OvmfPkg/OvmfPkgIa32X64.fdf
> > +++ b/OvmfPkg/OvmfPkgIa32X64.fdf
> > @@ -288,7 +288,7 @@ INF MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResour
> > INF FatPkg/EnhancedFatDxe/Fat.inf
> > INF MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
> >
> > -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> > +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
> > INF ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
> > !endif
> > INF ShellPkg/Application/Shell/Shell.inf
> > diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> > index 2927ee07b8..f28ec13c0c 100644
> > --- a/OvmfPkg/OvmfPkgX64.dsc
> > +++ b/OvmfPkg/OvmfPkgX64.dsc
> > @@ -78,12 +78,14 @@
> >
> > [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> > GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> > + CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
> > XCODE:*_*_*_DLINK_FLAGS =
> >
> > # Force PE/COFF sections to be aligned at 4KB boundaries to support page level
> > # protection of DXE_SMM_DRIVER/SMM_CORE modules
> > [BuildOptions.common.EDKII.DXE_SMM_DRIVER, BuildOptions.common.EDKII.SMM_CORE]
> > GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> > + CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
> > XCODE:*_*_*_DLINK_FLAGS =
> >
> > ################################################################################
> > @@ -839,7 +841,7 @@
> > OvmfPkg/Csm/Csm16/Csm16.inf
> > !endif
> >
> > -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> > +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
> > ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
> > <PcdsFixedAtBuild>
> > gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> > diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
> > index ccf36c5dd9..affce983f9 100644
> > --- a/OvmfPkg/OvmfPkgX64.fdf
> > +++ b/OvmfPkg/OvmfPkgX64.fdf
> > @@ -288,7 +288,7 @@ INF MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResour
> > INF FatPkg/EnhancedFatDxe/Fat.inf
> > INF MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
> >
> > -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> > +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
> > INF ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
> > !endif
> > INF ShellPkg/Application/Shell/Shell.inf
> > --
> > 2.13.0.windows.1
> >
> >
> >
> >
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [edk2-devel] [Patch 7/7] OvmfPkg: Update DSC/FDF to support CLANG8ELF tool chain
2019-04-26 14:42 ` [Patch 7/7] OvmfPkg: Update DSC/FDF to support CLANG8ELF tool chain Liming Gao
2019-05-19 13:24 ` [edk2-devel] " Ard Biesheuvel
@ 2019-05-20 14:33 ` Laszlo Ersek
1 sibling, 0 replies; 27+ messages in thread
From: Laszlo Ersek @ 2019-05-20 14:33 UTC (permalink / raw)
To: liming.gao; +Cc: devel, Ard Biesheuvel
On 04/26/19 16:42, Liming Gao wrote:
> Signed-off-by: Liming Gao <liming.gao@intel.com>
> ---
> OvmfPkg/OvmfPkgIa32.dsc | 4 +++-
> OvmfPkg/OvmfPkgIa32.fdf | 2 +-
> OvmfPkg/OvmfPkgIa32X64.dsc | 4 +++-
> OvmfPkg/OvmfPkgIa32X64.fdf | 2 +-
> OvmfPkg/OvmfPkgX64.dsc | 4 +++-
> OvmfPkg/OvmfPkgX64.fdf | 2 +-
> 6 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 98a8467e86..7972b25112 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -73,12 +73,14 @@
>
> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> + CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
> XCODE:*_*_*_DLINK_FLAGS =
>
> # Force PE/COFF sections to be aligned at 4KB boundaries to support page level
> # protection of DXE_SMM_DRIVER/SMM_CORE modules
> [BuildOptions.common.EDKII.DXE_SMM_DRIVER, BuildOptions.common.EDKII.SMM_CORE]
> GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> + CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
> XCODE:*_*_*_DLINK_FLAGS =
>
> ################################################################################
> @@ -832,7 +834,7 @@
> OvmfPkg/Csm/Csm16/Csm16.inf
> !endif
>
> -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
> ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
> <PcdsFixedAtBuild>
> gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
> index bc08bf2243..2894cfe8d6 100644
> --- a/OvmfPkg/OvmfPkgIa32.fdf
> +++ b/OvmfPkg/OvmfPkgIa32.fdf
> @@ -287,7 +287,7 @@ INF MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResour
> INF FatPkg/EnhancedFatDxe/Fat.inf
> INF MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
>
> -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
> INF ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
> !endif
> INF ShellPkg/Application/Shell/Shell.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 1f722fc987..c9feeafaae 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -78,12 +78,14 @@
>
> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> + CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
> XCODE:*_*_*_DLINK_FLAGS =
>
> # Force PE/COFF sections to be aligned at 4KB boundaries to support page level
> # protection of DXE_SMM_DRIVER/SMM_CORE modules
> [BuildOptions.common.EDKII.DXE_SMM_DRIVER, BuildOptions.common.EDKII.SMM_CORE]
> GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> + CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
> XCODE:*_*_*_DLINK_FLAGS =
>
> ################################################################################
> @@ -841,7 +843,7 @@
> OvmfPkg/Csm/Csm16/Csm16.inf
> !endif
>
> -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
> ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
> <PcdsFixedAtBuild>
> gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
> index ccf36c5dd9..affce983f9 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.fdf
> +++ b/OvmfPkg/OvmfPkgIa32X64.fdf
> @@ -288,7 +288,7 @@ INF MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResour
> INF FatPkg/EnhancedFatDxe/Fat.inf
> INF MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
>
> -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
> INF ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
> !endif
> INF ShellPkg/Application/Shell/Shell.inf
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 2927ee07b8..f28ec13c0c 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -78,12 +78,14 @@
>
> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> + CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
> XCODE:*_*_*_DLINK_FLAGS =
>
> # Force PE/COFF sections to be aligned at 4KB boundaries to support page level
> # protection of DXE_SMM_DRIVER/SMM_CORE modules
> [BuildOptions.common.EDKII.DXE_SMM_DRIVER, BuildOptions.common.EDKII.SMM_CORE]
> GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> + CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
> XCODE:*_*_*_DLINK_FLAGS =
>
> ################################################################################
> @@ -839,7 +841,7 @@
> OvmfPkg/Csm/Csm16/Csm16.inf
> !endif
>
> -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
> ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
> <PcdsFixedAtBuild>
> gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
> index ccf36c5dd9..affce983f9 100644
> --- a/OvmfPkg/OvmfPkgX64.fdf
> +++ b/OvmfPkg/OvmfPkgX64.fdf
> @@ -288,7 +288,7 @@ INF MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResour
> INF FatPkg/EnhancedFatDxe/Fat.inf
> INF MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
>
> -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
> INF ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
> !endif
> INF ShellPkg/Application/Shell/Shell.inf
>
I'll defer to Ard on this patch.
In case Ard accepts this patch ultimately, you can also add my:
Acked-by: Laszlo Ersek <lersek@redhat.com>
Because, the modifications look at least consistent, and regression-free
too.
Thanks
Laszlo
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8
2019-04-26 14:42 [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8 Liming Gao
` (6 preceding siblings ...)
2019-04-26 14:42 ` [Patch 7/7] OvmfPkg: Update DSC/FDF to support CLANG8ELF tool chain Liming Gao
@ 2019-04-26 16:33 ` Ard Biesheuvel
2019-04-28 0:55 ` Liming Gao
[not found] ` <15990D503F545BBC.4588@groups.io>
2019-05-21 21:13 ` [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8 Laszlo Ersek
9 siblings, 1 reply; 27+ messages in thread
From: Ard Biesheuvel @ 2019-04-26 16:33 UTC (permalink / raw)
To: edk2-devel-groups-io, Gao, Liming
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
>
>
>
>
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8
2019-04-26 16:33 ` [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8 Ard Biesheuvel
@ 2019-04-28 0:55 ` Liming Gao
2019-04-29 16:51 ` Leif Lindholm
2019-05-19 20:14 ` Jordan Justen
0 siblings, 2 replies; 27+ messages in thread
From: Liming Gao @ 2019-04-28 0:55 UTC (permalink / raw)
To: Ard Biesheuvel, edk2-devel-groups-io
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
>>
>>
>>
>>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8
2019-04-28 0:55 ` Liming Gao
@ 2019-04-29 16:51 ` Leif Lindholm
2019-04-30 4:21 ` Liming Gao
2019-05-19 20:14 ` Jordan Justen
1 sibling, 1 reply; 27+ messages in thread
From: Leif Lindholm @ 2019-04-29 16:51 UTC (permalink / raw)
To: devel, liming.gao; +Cc: Ard Biesheuvel
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
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8
2019-04-29 16:51 ` Leif Lindholm
@ 2019-04-30 4:21 ` Liming Gao
2019-04-30 11:01 ` Leif Lindholm
0 siblings, 1 reply; 27+ messages in thread
From: Liming Gao @ 2019-04-30 4:21 UTC (permalink / raw)
To: devel@edk2.groups.io, leif.lindholm@linaro.org; +Cc: Ard Biesheuvel
> -----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
>
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8
2019-04-30 4:21 ` Liming Gao
@ 2019-04-30 11:01 ` Leif Lindholm
2019-04-30 13:11 ` Steven Shi
` (2 more replies)
0 siblings, 3 replies; 27+ messages in thread
From: Leif Lindholm @ 2019-04-30 11:01 UTC (permalink / raw)
To: devel, liming.gao; +Cc: Ard Biesheuvel
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
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8
2019-04-30 11:01 ` Leif Lindholm
@ 2019-04-30 13:11 ` Steven Shi
2019-05-05 6:18 ` Liming Gao
[not found] ` <159BB5054AE8ABA6.12625@groups.io>
2 siblings, 0 replies; 27+ messages in thread
From: Steven Shi @ 2019-04-30 13:11 UTC (permalink / raw)
To: devel@edk2.groups.io, leif.lindholm@linaro.org, Gao, Liming
Cc: Ard Biesheuvel
> 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
>
>
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8
2019-04-30 11:01 ` Leif Lindholm
2019-04-30 13:11 ` Steven Shi
@ 2019-05-05 6:18 ` Liming Gao
[not found] ` <159BB5054AE8ABA6.12625@groups.io>
2 siblings, 0 replies; 27+ messages in thread
From: Liming Gao @ 2019-05-05 6:18 UTC (permalink / raw)
To: devel@edk2.groups.io, leif.lindholm@linaro.org; +Cc: Ard Biesheuvel
>-----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
>
>
^ permalink raw reply [flat|nested] 27+ messages in thread[parent not found: <159BB5054AE8ABA6.12625@groups.io>]
* Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8
[not found] ` <159BB5054AE8ABA6.12625@groups.io>
@ 2019-05-16 13:29 ` Liming Gao
0 siblings, 0 replies; 27+ messages in thread
From: Liming Gao @ 2019-05-16 13:29 UTC (permalink / raw)
To: devel@edk2.groups.io, Gao, Liming, leif.lindholm@linaro.org
Cc: Ard Biesheuvel
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
> >
> >
>
>
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8
2019-04-28 0:55 ` Liming Gao
2019-04-29 16:51 ` Leif Lindholm
@ 2019-05-19 20:14 ` Jordan Justen
2019-05-20 13:47 ` Liming Gao
1 sibling, 1 reply; 27+ messages in thread
From: Jordan Justen @ 2019-05-19 20:14 UTC (permalink / raw)
To: Ard Biesheuvel, Liming Gao, edk2-devel-groups-io
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8
2019-05-19 20:14 ` Jordan Justen
@ 2019-05-20 13:47 ` Liming Gao
2019-05-20 22:52 ` Andrew Fish
0 siblings, 1 reply; 27+ messages in thread
From: Liming Gao @ 2019-05-20 13:47 UTC (permalink / raw)
To: Justen, Jordan L, Ard Biesheuvel, edk2-devel-groups-io
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8
2019-05-20 13:47 ` Liming Gao
@ 2019-05-20 22:52 ` Andrew Fish
2019-05-21 2:18 ` Liming Gao
0 siblings, 1 reply; 27+ messages in thread
From: Andrew Fish @ 2019-05-20 22:52 UTC (permalink / raw)
To: devel, Gao, Liming; +Cc: Jordan Justen, Ard Biesheuvel
[-- Attachment #1: Type: text/plain, Size: 5352 bytes --]
> 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
>
>
[-- Attachment #2: Type: text/html, Size: 14940 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8
2019-05-20 22:52 ` Andrew Fish
@ 2019-05-21 2:18 ` Liming Gao
2019-05-21 3:36 ` Andrew Fish
0 siblings, 1 reply; 27+ messages in thread
From: Liming Gao @ 2019-05-21 2:18 UTC (permalink / raw)
To: afish@apple.com, devel@edk2.groups.io; +Cc: Justen, Jordan L, Ard Biesheuvel
[-- Attachment #1: Type: text/plain, Size: 6030 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 17099 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8
2019-05-21 2:18 ` Liming Gao
@ 2019-05-21 3:36 ` Andrew Fish
0 siblings, 0 replies; 27+ messages in thread
From: Andrew Fish @ 2019-05-21 3:36 UTC (permalink / raw)
To: devel, Liming Gao; +Cc: Jordan Justen, Ard Biesheuvel
[-- Attachment #1: Type: text/plain, Size: 7531 bytes --]
> 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
>
>
>
[-- Attachment #2: Type: text/html, Size: 27142 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <15990D503F545BBC.4588@groups.io>]
* Re: [edk2-devel] [Patch 7/7] OvmfPkg: Update DSC/FDF to support CLANG8ELF tool chain
[not found] ` <15990D503F545BBC.4588@groups.io>
@ 2019-05-19 11:59 ` Liming Gao
0 siblings, 0 replies; 27+ messages in thread
From: Liming Gao @ 2019-05-19 11:59 UTC (permalink / raw)
To: devel@edk2.groups.io, Gao, Liming
Cc: Justen, Jordan L, Laszlo Ersek (lersek@redhat.com),
ard.biesheuvel@linaro.org
Cc to OvmfPkg maintainers. Please help review this change.
Thanks
Liming
> -----Original Message-----
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Liming Gao
> Sent: Friday, April 26, 2019 10:43 PM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] [Patch 7/7] OvmfPkg: Update DSC/FDF to support CLANG8ELF tool chain
>
> Signed-off-by: Liming Gao <liming.gao@intel.com>
> ---
> OvmfPkg/OvmfPkgIa32.dsc | 4 +++-
> OvmfPkg/OvmfPkgIa32.fdf | 2 +-
> OvmfPkg/OvmfPkgIa32X64.dsc | 4 +++-
> OvmfPkg/OvmfPkgIa32X64.fdf | 2 +-
> OvmfPkg/OvmfPkgX64.dsc | 4 +++-
> OvmfPkg/OvmfPkgX64.fdf | 2 +-
> 6 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 98a8467e86..7972b25112 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -73,12 +73,14 @@
>
> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> + CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
> XCODE:*_*_*_DLINK_FLAGS =
>
> # Force PE/COFF sections to be aligned at 4KB boundaries to support page level
> # protection of DXE_SMM_DRIVER/SMM_CORE modules
> [BuildOptions.common.EDKII.DXE_SMM_DRIVER, BuildOptions.common.EDKII.SMM_CORE]
> GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> + CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
> XCODE:*_*_*_DLINK_FLAGS =
>
> ################################################################################
> @@ -832,7 +834,7 @@
> OvmfPkg/Csm/Csm16/Csm16.inf
> !endif
>
> -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
> ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
> <PcdsFixedAtBuild>
> gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
> index bc08bf2243..2894cfe8d6 100644
> --- a/OvmfPkg/OvmfPkgIa32.fdf
> +++ b/OvmfPkg/OvmfPkgIa32.fdf
> @@ -287,7 +287,7 @@ INF MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResour
> INF FatPkg/EnhancedFatDxe/Fat.inf
> INF MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
>
> -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
> INF ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
> !endif
> INF ShellPkg/Application/Shell/Shell.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 1f722fc987..c9feeafaae 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -78,12 +78,14 @@
>
> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> + CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
> XCODE:*_*_*_DLINK_FLAGS =
>
> # Force PE/COFF sections to be aligned at 4KB boundaries to support page level
> # protection of DXE_SMM_DRIVER/SMM_CORE modules
> [BuildOptions.common.EDKII.DXE_SMM_DRIVER, BuildOptions.common.EDKII.SMM_CORE]
> GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> + CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
> XCODE:*_*_*_DLINK_FLAGS =
>
> ################################################################################
> @@ -841,7 +843,7 @@
> OvmfPkg/Csm/Csm16/Csm16.inf
> !endif
>
> -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
> ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
> <PcdsFixedAtBuild>
> gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
> index ccf36c5dd9..affce983f9 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.fdf
> +++ b/OvmfPkg/OvmfPkgIa32X64.fdf
> @@ -288,7 +288,7 @@ INF MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResour
> INF FatPkg/EnhancedFatDxe/Fat.inf
> INF MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
>
> -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
> INF ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
> !endif
> INF ShellPkg/Application/Shell/Shell.inf
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 2927ee07b8..f28ec13c0c 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -78,12 +78,14 @@
>
> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> + CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
> XCODE:*_*_*_DLINK_FLAGS =
>
> # Force PE/COFF sections to be aligned at 4KB boundaries to support page level
> # protection of DXE_SMM_DRIVER/SMM_CORE modules
> [BuildOptions.common.EDKII.DXE_SMM_DRIVER, BuildOptions.common.EDKII.SMM_CORE]
> GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> + CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
> XCODE:*_*_*_DLINK_FLAGS =
>
> ################################################################################
> @@ -839,7 +841,7 @@
> OvmfPkg/Csm/Csm16/Csm16.inf
> !endif
>
> -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
> ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
> <PcdsFixedAtBuild>
> gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
> index ccf36c5dd9..affce983f9 100644
> --- a/OvmfPkg/OvmfPkgX64.fdf
> +++ b/OvmfPkg/OvmfPkgX64.fdf
> @@ -288,7 +288,7 @@ INF MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResour
> INF FatPkg/EnhancedFatDxe/Fat.inf
> INF MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
>
> -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
> INF ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
> !endif
> INF ShellPkg/Application/Shell/Shell.inf
> --
> 2.13.0.windows.1
>
>
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8
2019-04-26 14:42 [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8 Liming Gao
` (8 preceding siblings ...)
[not found] ` <15990D503F545BBC.4588@groups.io>
@ 2019-05-21 21:13 ` Laszlo Ersek
9 siblings, 0 replies; 27+ messages in thread
From: Laszlo Ersek @ 2019-05-21 21:13 UTC (permalink / raw)
To: devel, liming.gao
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
^ permalink raw reply [flat|nested] 27+ messages in thread