[Patch v3 00/11] New Cross OS tool chain CLANG9

[Patch v3 00/11] New Cross OS tool chain CLANG9

[Liming Gao]

In v3, add the detail commit message for patch 3. 
Update the fix in EmulatorPkg based on the comments.

In v2, drop patch 12, and update commit message for 5 & 11.

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
Code: https://github.com/lgao4/edk2/tree/CLANG9
Wiki: https://github.com/lgao4/edk2/wiki/CLANG9-Tools-Chain

CLANG9 tool chain is added to directly generate PE/COFF image (EFI image).
This tool chain uses LLVM clang C compiler and lld linker, generates PE/COFF
image and PDB compatible debug symbol format. Now, it supports IA32/X64 Archs.
It must use LLVM 9 or above release. LLVM 9 is ready on 
http://releases.llvm.org/download.html#9.0.0.

CLANG9 is the cross OS tool chain. It can work on Windows/Linux/Mac host OS. 
For the same source code, with the same version LLVM tool chain, 
CLANG9 can generate the same binary image. So, the developer can 
choose the different development environment and work on the same 
code base. Besides, EDKII project build also requires third party 
tools: nasm and iasl. They both keep the same version. If so, the same 
binary image can be generated on the different host OS.

LLVM tool chain provides the compiler and linker. To build EDK2 project, 
some other tools are still required. On Windows OS, nmake and Visual Studio 
are required to call Makefile and compile BaseTools C tools. 
On Linux/Mac, binutils and gcc are required to make and compile BaseTools 
C tools. Because VS or GCC are mainly used to compile BaseTools and provide 
nmake/make tool, they can keep on the stable version without update.

To build source code, CLANG9 tool chain (-t CLANG9) can be specified
on Windows OS, set CLANG_HOST_BIN=n, set CLANG9_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 CLANG9_BIN=C:\Program Files\LLVM\bin\
*  set IASL_PREFIX=C:\Asl\

On Linux/Mac, export CLANG9_BIN=LLVM installed directory, CLANG_HOST_BIN is 
not required, because there is no prefix for make.
For example:
*  export CLANG9_BIN=/home/clang9/bin/

Now, CLANG9 tool chain has been verified in Edk2 packages and Ovmf/Emulator
with LLVM 9.0.0 on Windows and Linux OS. 
OVMF IA32/X64/IA32X64 all boots to Shell on Windows and Linux OS. 
Emulator can boot to Shell on Windows only with CLANG9.
OVMF Ia32X64 RELEASE build generates the same BIOS images on Windows and Linux OS.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Steven Shi <steven.shi@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>

Liming Gao (11):
  BaseTools tools_def.template: Remove unnecessary $(DEST_DIR_DEBUG)
    path
  BaseTools tools_def: Add CLANG9 tool chain to directly generate PE
    image
  BaseTools GenFw: Fix the issue to update the wrong size as SectionSize
  MdePkg Base.h: Add definition for CLANG9 tool chain
  MdePkg BaseIoLibIntrinsic: Remove __inline__ attribute for IO
    functions
  MdeModulePkg LzmaCustomDecompressLib: Update macro to be same in CLANG
    tool
  MdeModulePkg RegularExpressionDxe: Disable warning for CLANG9 tool
    chain
  CryptoPkg: Append options to make CLANG9 tool chain pass build
  CryptoPkg IntrinsicLib: Make _fltused always be used
  EmulatorPkg: Enable CLANG9 tool chain
  OvmfPkg: Enable CLANG9 tool chain

 BaseTools/Source/C/GenFw/GenFw.c                   |   8 +-
 CryptoPkg/Library/IntrinsicLib/MemoryIntrinsics.c  |  10 +-
 EmulatorPkg/Win/Host/WinHost.c                     |   6 +-
 MdePkg/Library/BaseIoLibIntrinsic/IoLibGcc.c       |   6 -
 BaseTools/Conf/build_rule.template                 |  26 +++--
 BaseTools/Conf/tools_def.template                  | 124 +++++++++++++++++++--
 CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf    |   1 +
 CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf     |   1 +
 CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf |   1 +
 CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf     |   1 +
 CryptoPkg/Library/OpensslLib/OpensslLib.inf        |   1 +
 CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf  |   1 +
 EmulatorPkg/EmulatorPkg.dsc                        |   7 +-
 EmulatorPkg/Win/Host/WinHost.inf                   |   6 +
 .../LzmaCustomDecompressLib/Sdk/C/7zTypes.h        |   2 +-
 .../RegularExpressionDxe/RegularExpressionDxe.inf  |   3 +
 MdePkg/Include/Base.h                              |   6 +-
 MdePkg/Include/Ia32/ProcessorBind.h                |   4 +-
 MdePkg/Include/X64/ProcessorBind.h                 |   2 +-
 OvmfPkg/OvmfPkgIa32.dsc                            |   4 +-
 OvmfPkg/OvmfPkgIa32X64.dsc                         |   4 +-
 OvmfPkg/OvmfPkgX64.dsc                             |   4 +-
 22 files changed, 183 insertions(+), 45 deletions(-)

-- 
2.13.0.windows.1

[Patch v3 01/11] BaseTools tools_def.template: Remove unnecessary $(DEST_DIR_DEBUG) path

[Liming Gao]

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
$(DEST_DIR_DEBUG) path is in Include directory.
It is not required to be specified again.

Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
---
 BaseTools/Conf/tools_def.template | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template
index 88a6764f43..fd6fca542d 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -350,8 +350,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
 #
 ####################################################################################
@@ -1906,13 +1906,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
@@ -2772,8 +2772,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 -gdwarf -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 -gdwarf -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)
@@ -2812,7 +2812,7 @@ RELEASE_RVCT_ARM_DLINK_FLAGS     = $(ARCHDLINK_FLAGS) DEF(RVCT_ALL_DLINK_FLAGS)
 
 *_RVCT_ARM_ASM_FLAGS       = $(ARCHASM_FLAGS) $(PLATFORM_FLAGS) DEF(RVCT_ALL_ASM_FLAGS)
 *_RVCT_ARM_PP_FLAGS        = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -E --preinclude AutoGen.h
-*_RVCT_ARM_VFRPP_FLAGS     = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -E  -DVFRCOMPILE --preinclude $(DEST_DIR_DEBUG)/$(MODULE_NAME)StrDefs.h
+*_RVCT_ARM_VFRPP_FLAGS     = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -E  -DVFRCOMPILE --preinclude $(MODULE_NAME)StrDefs.h
 *_RVCT_ARM_MAKE_PATH       = nmake /NOLOGO
 *_RVCT_ARM_SLINK_FLAGS     = --partial -o
   DEBUG_RVCT_ARM_CC_FLAGS  = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(RVCT_ALL_CC_FLAGS) -O1 -g
@@ -2853,7 +2853,7 @@ RELEASE_RVCTLINUX_ARM_DLINK_FLAGS   = $(ARCHDLINK_FLAGS) DEF(RVCT_ALL_DLINK_FLAG
 
 *_RVCTLINUX_ARM_ASM_FLAGS       = $(ARCHASM_FLAGS) $(PLATFORM_FLAGS) DEF(RVCT_ALL_ASM_FLAGS)
 *_RVCTLINUX_ARM_PP_FLAGS        = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -E
-*_RVCTLINUX_ARM_VFRPP_FLAGS     = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -E  -DVFRCOMPILE --preinclude $(DEST_DIR_DEBUG)/$(MODULE_NAME)StrDefs.h
+*_RVCTLINUX_ARM_VFRPP_FLAGS     = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -E  -DVFRCOMPILE --preinclude $(MODULE_NAME)StrDefs.h
 *_RVCTLINUX_ARM_SLINK_FLAGS     = --partial -o
   DEBUG_RVCTLINUX_ARM_CC_FLAGS  = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(RVCT_ALL_CC_FLAGS) -O1 -g
 RELEASE_RVCTLINUX_ARM_CC_FLAGS  = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) --diag_suppress=550 DEF(RVCT_ALL_CC_FLAGS) -O2
@@ -2900,7 +2900,7 @@ RELEASE_RVCTCYGWIN_ARM_DLINK_FLAGS     = "$(DLINKPATH_FLAG)" $(ARCHDLINK_FLAGS)
 
 *_RVCTCYGWIN_ARM_ASM_FLAGS       = "$(ASMPATH_FLAG)" $(ARCHASM_FLAGS) $(PLATFORM_FLAGS) DEF(RVCT_ALL_ASM_FLAGS)
 *_RVCTCYGWIN_ARM_PP_FLAGS        = "$(CCPATH_FLAG)" $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -E
-*_RVCTCYGWIN_ARM_VFRPP_FLAGS     = "$(CCPATH_FLAG)" $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -E  -DVFRCOMPILE --preinclude `cygpath -m $(DEST_DIR_DEBUG)/$(MODULE_NAME)StrDefs.h`
+*_RVCTCYGWIN_ARM_VFRPP_FLAGS     = "$(CCPATH_FLAG)" $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -E  -DVFRCOMPILE --preinclude `cygpath -m $(MODULE_NAME)StrDefs.h`
 *_RVCTCYGWIN_ARM_MAKE_PATH       = make
 *_RVCTCYGWIN_ARM_SLINK_FLAGS     = "$(SLINKPATH_FLAG)" --partial -o
   DEBUG_RVCTCYGWIN_ARM_CC_FLAGS  = "$(CCPATH_FLAG)" $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(RVCT_ALL_CC_FLAGS) -O1 -g
-- 
2.13.0.windows.1

[Patch v3 02/11] BaseTools tools_def: Add CLANG9 tool chain to directly generate PE image

[Liming Gao]

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603

Signed-off-by: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
---
 BaseTools/Conf/build_rule.template |  26 ++++++----
 BaseTools/Conf/tools_def.template  | 102 +++++++++++++++++++++++++++++++++++++
 2 files changed, 118 insertions(+), 10 deletions(-)

diff --git a/BaseTools/Conf/build_rule.template b/BaseTools/Conf/build_rule.template
index db06d3a6b4..3a58ac8015 100755
--- a/BaseTools/Conf/build_rule.template
+++ b/BaseTools/Conf/build_rule.template
@@ -260,7 +260,7 @@
     <OutputFile>
         $(OUTPUT_DIR)(+)$(MODULE_NAME).lib
 
-    <Command.MSFT, Command.INTEL>
+    <Command.MSFT, Command.INTEL, Command.CLANGPE>
         "$(SLINK)" $(SLINK_FLAGS) /OUT:${dst} @$(OBJECT_FILES_LIST)
 
     <Command.GCC>
@@ -291,6 +291,9 @@
         "$(DLINK)" /OUT:${dst} $(DLINK_FLAGS) $(DLINK2_FLAGS) $(DLINK_SPATH) @$(STATIC_LIBRARY_FILES_LIST)
         "$(DLINK)" /OUT:${dst} $(DLINK_FLAGS) $(DLINK_SPATH) @$(STATIC_LIBRARY_FILES_LIST)
 
+    <Command.CLANGPE>
+        "$(DLINK)" /OUT:${dst} $(DLINK_FLAGS) $(DLINK_SPATH) @$(STATIC_LIBRARY_FILES_LIST) $(DLINK2_FLAGS)
+
     <Command.GCC>
         "$(DLINK)" -o ${dst} $(DLINK_FLAGS) -Wl,--start-group,@$(STATIC_LIBRARY_FILES_LIST),--end-group $(CC_FLAGS) $(DLINK2_FLAGS)
         "$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
@@ -331,7 +334,7 @@
     <OutputFile>
         $(DEBUG_DIR)(+)$(MODULE_NAME)
 
-    <Command.MSFT, Command.INTEL>
+    <Command.MSFT, Command.INTEL, Command.CLANGPE>
         "$(DLINK)" $(DLINK_FLAGS) $(DLINK_SPATH) @$(STATIC_LIBRARY_FILES_LIST)
 
     <Command.GCC>
@@ -355,7 +358,7 @@
     <OutputFile>
         $(OUTPUT_DIR)(+)$(MODULE_NAME).efi
 
-    <Command.MSFT, Command.INTEL, Command.RVCT>
+    <Command.MSFT, Command.INTEL, Command.RVCT, Command.CLANGPE>
         "$(GENFW)" -e $(MODULE_TYPE) -o ${dst} ${src} $(GENFW_FLAGS)
         $(CP) ${dst} $(DEBUG_DIR)
         $(CP) ${dst} $(BIN_DIR)(+)$(MODULE_NAME_GUID).efi
@@ -460,9 +463,14 @@
 
     <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.CLANGPE>
+        "$(ASLCC)" -c -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj $(CC_FLAGS) $(ASLCC_FLAGS) $(INC) ${src}
+        "$(ASLDLINK)" /OUT:$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll $(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
+        "$(GENFW)" -o ${dst} -c $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll $(GENFW_FLAGS)
+
     <Command.XCODE>        
         "$(ASLCC)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj  $(ASLCC_FLAGS) $(INC) ${src}
         "$(ASLDLINK)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll $(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
@@ -622,21 +630,19 @@
     <InputFile>
         *.hpk
 
-    <OutputFile.MSFT, OutputFile.INTEL, OutputFile.GCC>
+    <OutputFile.MSFT, OutputFile.INTEL, OutputFile.GCC, OutputFile.CLANGPE>
         $(OUTPUT_DIR)(+)$(MODULE_NAME)hii.lib
 
     <OutputFile.XCODE, OutputFile.RVCT>
         $(OUTPUT_DIR)(+)$(MODULE_NAME)hii.rc
 
-    <Command.MSFT, Command.INTEL>
+    <Command.MSFT, Command.INTEL, Command.CLANGPE>
         "$(GENFW)" -o $(OUTPUT_DIR)(+)$(MODULE_NAME)hii.rc -g $(MODULE_GUID) --hiipackage $(HII_BINARY_PACKAGES) $(GENFW_FLAGS)
         "$(RC)" /Fo${dst} $(OUTPUT_DIR)(+)$(MODULE_NAME)hii.rc
 
     <Command.GCC>
         "$(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)
-        
-        
diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template
index fd6fca542d..b4bc27ab25 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -268,6 +268,15 @@ DEFINE DTC_BIN                 = ENV(DTC_PREFIX)dtc
 #                             Required to build platforms or ACPI tables:
 #                               Intel(r) ACPI Compiler from
 #                               https://acpica.org/downloads
+#   CLANG9   -Linux, Windows, Mac-  Requires:
+#                             Clang 9 or above from http://releases.llvm.org/
+#                        Optional:
+#                             Required to compile nasm source:
+#                               nasm compiler from
+#                               NASM -- http://www.nasm.us/
+#                             Required to build platforms or ACPI tables:
+#                               Intel(r) ACPI Compiler from
+#                               https://acpica.org/downloads
 #   VS2008x86   -win64-  Requires:
 #                             Microsoft Visual Studio 2008 (x86)
 #                             Microsoft Windows Server 2003 Driver Development Kit (Microsoft WINDDK) version 3790.1830
@@ -2698,6 +2707,99 @@ 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
 
+####################################################################################
+#
+# CLANG9 - This configuration is used to compile under Windows/Linux/Mac to produce
+#  PE/COFF binaries using LLVM/Clang/LLD with Link Time Optimization enabled
+#
+####################################################################################
+*_CLANG9_*_*_FAMILY                = GCC
+*_CLANG9_*_*_BUILDRULEFAMILY       = CLANGPE
+*_CLANG9_*_MAKE_PATH               = ENV(CLANG_HOST_BIN)make
+*_CLANG9_*_*_DLL                   = ENV(CLANG9_DLL)
+*_CLANG9_*_ASL_PATH                = DEF(UNIX_IASL_BIN)
+
+*_CLANG9_*_APP_FLAGS               =
+*_CLANG9_*_ASL_FLAGS               = DEF(DEFAULT_WIN_ASL_FLAGS)
+*_CLANG9_*_ASL_OUTFLAGS            = DEF(DEFAULT_WIN_ASL_OUTFLAGS)
+*_CLANG9_*_ASLDLINK_FLAGS          = DEF(MSFT_ASLDLINK_FLAGS)
+
+DEFINE CLANG9_IA32_PREFIX          = ENV(CLANG9_BIN)
+DEFINE CLANG9_X64_PREFIX           = ENV(CLANG9_BIN)
+
+DEFINE CLANG9_IA32_TARGET          = -target i686-unknown-windows
+DEFINE CLANG9_X64_TARGET           = -target x86_64-unknown-windows
+
+DEFINE CLANG9_WARNING_OVERRIDES    = -Wno-parentheses-equality -Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare -Wno-empty-body -Wno-unused-const-variable -Wno-varargs -Wno-unknown-warning-option -Wno-microsoft-enum-forward-reference
+DEFINE CLANG9_ALL_CC_FLAGS         = DEF(GCC48_ALL_CC_FLAGS) DEF(CLANG9_WARNING_OVERRIDES) -fno-stack-protector -mms-bitfields -Wno-address -Wno-shift-negative-value -Wno-unknown-pragmas -Wno-incompatible-library-redeclaration -fno-asynchronous-unwind-tables -mno-implicit-float  -ftrap-function=undefined_behavior_has_been_optimized_away_by_clang -funsigned-char -fno-ms-extensions -Wno-null-dereference -fms-compatibility -mno-stack-arg-probe
+
+###########################
+# CLANG9 IA32 definitions
+###########################
+*_CLANG9_IA32_CC_PATH              = DEF(CLANG9_IA32_PREFIX)clang
+*_CLANG9_IA32_SLINK_PATH           = DEF(CLANG9_IA32_PREFIX)llvm-lib
+*_CLANG9_IA32_DLINK_PATH           = DEF(CLANG9_IA32_PREFIX)lld-link
+*_CLANG9_IA32_ASLDLINK_PATH        = DEF(CLANG9_IA32_PREFIX)lld-link
+*_CLANG9_IA32_ASM_PATH             = DEF(CLANG9_IA32_PREFIX)clang
+*_CLANG9_IA32_PP_PATH              = DEF(CLANG9_IA32_PREFIX)clang
+*_CLANG9_IA32_VFRPP_PATH           = DEF(CLANG9_IA32_PREFIX)clang
+*_CLANG9_IA32_ASLCC_PATH           = DEF(CLANG9_IA32_PREFIX)clang
+*_CLANG9_IA32_ASLPP_PATH           = DEF(CLANG9_IA32_PREFIX)clang
+*_CLANG9_IA32_RC_PATH              = DEF(CLANG9_IA32_PREFIX)llvm-rc
+
+*_CLANG9_IA32_ASLCC_FLAGS          = DEF(GCC_ASLCC_FLAGS) -m32 -fno-lto DEF(CLANG9_IA32_TARGET)
+*_CLANG9_IA32_ASM_FLAGS            = DEF(GCC5_ASM_FLAGS) -m32 -march=i386 DEF(CLANG9_IA32_TARGET)
+*_CLANG9_IA32_OBJCOPY_FLAGS        =
+*_CLANG9_IA32_NASM_FLAGS           = -f win32
+*_CLANG9_IA32_PP_FLAGS             = DEF(GCC_PP_FLAGS) DEF(CLANG9_IA32_TARGET)
+*_CLANG9_IA32_ASLPP_FLAGS          = DEF(GCC_ASLPP_FLAGS) DEF(CLANG9_IA32_TARGET)
+*_CLANG9_IA32_VFRPP_FLAGS          = DEF(GCC_VFRPP_FLAGS) DEF(CLANG9_IA32_TARGET)
+
+DEBUG_CLANG9_IA32_CC_FLAGS         = DEF(CLANG9_ALL_CC_FLAGS) -m32 -Oz -flto -march=i586 DEF(CLANG9_IA32_TARGET) -gcodeview
+DEBUG_CLANG9_IA32_DLINK_FLAGS      = /NOLOGO /NODEFAULTLIB /IGNORE:4001 /OPT:REF /OPT:ICF=10 /ALIGN:32 /FILEALIGN:32 /SECTION:.xdata,D /SECTION:.pdata,D /MACHINE:X86 /DLL /ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:0 /DEBUG:GHASH  /lldmap
+DEBUG_CLANG9_IA32_DLINK2_FLAGS     =
+
+RELEASE_CLANG9_IA32_CC_FLAGS       = DEF(CLANG9_ALL_CC_FLAGS) -m32 -Oz -flto -march=i586 DEF(CLANG9_IA32_TARGET)
+RELEASE_CLANG9_IA32_DLINK_FLAGS    = /NOLOGO /NODEFAULTLIB /IGNORE:4001 /IGNORE:4254 /OPT:REF /OPT:ICF=10 /ALIGN:32 /FILEALIGN:32 /SECTION:.xdata,D /SECTION:.pdata,D /MACHINE:X86 /DLL /ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:0 /MERGE:.rdata=.data  /lldmap
+RELEASE_CLANG9_IA32_DLINK2_FLAGS   =
+
+NOOPT_CLANG9_IA32_CC_FLAGS         = DEF(CLANG9_ALL_CC_FLAGS) -m32 -O0 -march=i586 DEF(CLANG9_IA32_TARGET) -gcodeview
+NOOPT_CLANG9_IA32_DLINK_FLAGS      = /NOLOGO /NODEFAULTLIB /IGNORE:4001 /OPT:REF /OPT:ICF=10 /ALIGN:32 /FILEALIGN:32 /SECTION:.xdata,D /SECTION:.pdata,D /MACHINE:X86 /DLL /ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:0 /DEBUG:GHASH  /lldmap
+NOOPT_CLANG9_IA32_DLINK2_FLAGS     =
+
+##########################
+# CLANGWIN X64 definitions
+##########################
+*_CLANG9_X64_CC_PATH              = DEF(CLANG9_X64_PREFIX)clang
+*_CLANG9_X64_SLINK_PATH           = DEF(CLANG9_X64_PREFIX)llvm-lib
+*_CLANG9_X64_DLINK_PATH           = DEF(CLANG9_X64_PREFIX)lld-link
+*_CLANG9_X64_ASLDLINK_PATH        = DEF(CLANG9_X64_PREFIX)lld-link
+*_CLANG9_X64_ASM_PATH             = DEF(CLANG9_X64_PREFIX)clang
+*_CLANG9_X64_PP_PATH              = DEF(CLANG9_X64_PREFIX)clang
+*_CLANG9_X64_VFRPP_PATH           = DEF(CLANG9_X64_PREFIX)clang
+*_CLANG9_X64_ASLCC_PATH           = DEF(CLANG9_X64_PREFIX)clang
+*_CLANG9_X64_ASLPP_PATH           = DEF(CLANG9_X64_PREFIX)clang
+*_CLANG9_X64_RC_PATH              = DEF(CLANG9_IA32_PREFIX)llvm-rc
+
+*_CLANG9_X64_ASLCC_FLAGS          = DEF(GCC_ASLCC_FLAGS) -m64 -fno-lto DEF(CLANG9_X64_TARGET)
+*_CLANG9_X64_ASM_FLAGS            = DEF(GCC5_ASM_FLAGS) -m64 DEF(CLANG9_X64_TARGET)
+*_CLANG9_X64_OBJCOPY_FLAGS        =
+*_CLANG9_X64_NASM_FLAGS           = -f win64
+*_CLANG9_X64_PP_FLAGS             = DEF(GCC_PP_FLAGS) DEF(CLANG9_X64_TARGET)
+*_CLANG9_X64_ASLPP_FLAGS          = DEF(GCC_ASLPP_FLAGS) DEF(CLANG9_X64_TARGET)
+*_CLANG9_X64_VFRPP_FLAGS          = DEF(GCC_VFRPP_FLAGS) DEF(CLANG9_X64_TARGET)
+
+DEBUG_CLANG9_X64_CC_FLAGS         = DEF(CLANG9_ALL_CC_FLAGS) -m64 "-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone -mcmodel=small -Oz -flto DEF(CLANG9_X64_TARGET) -gcodeview
+DEBUG_CLANG9_X64_DLINK_FLAGS      = /NOLOGO /NODEFAULTLIB /IGNORE:4001 /OPT:REF /OPT:ICF=10 /ALIGN:32 /FILEALIGN:32 /SECTION:.xdata,D /SECTION:.pdata,D /Machine:X64 /DLL /ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:0 /DEBUG:GHASH  /lldmap
+DEBUG_CLANG9_X64_DLINK2_FLAGS     =
+
+RELEASE_CLANG9_X64_CC_FLAGS       = DEF(CLANG9_ALL_CC_FLAGS) -m64 "-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone -mcmodel=small -Oz -flto DEF(CLANG9_X64_TARGET)
+RELEASE_CLANG9_X64_DLINK_FLAGS    = /NOLOGO /NODEFAULTLIB /IGNORE:4001 /IGNORE:4254 /OPT:REF /OPT:ICF=10 /ALIGN:32 /FILEALIGN:32 /SECTION:.xdata,D /SECTION:.pdata,D /Machine:X64 /DLL /ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:0 /MERGE:.rdata=.data  /lldmap
+RELEASE_CLANG9_X64_DLINK2_FLAGS   =
+
+NOOPT_CLANG9_X64_CC_FLAGS         = DEF(CLANG9_ALL_CC_FLAGS) -m64 "-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone -mcmodel=small -O0 DEF(CLANG9_X64_TARGET) -gcodeview
+NOOPT_CLANG9_X64_DLINK_FLAGS      = /NOLOGO /NODEFAULTLIB /IGNORE:4001 /OPT:REF /OPT:ICF=10 /ALIGN:32 /FILEALIGN:32 /SECTION:.xdata,D /SECTION:.pdata,D /Machine:X64 /DLL /ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:0 /DEBUG:GHASH  /lldmap
+NOOPT_CLANG9_X64_DLINK2_FLAGS     =
 
 
 #
-- 
2.13.0.windows.1

Re: [Patch v3 02/11] BaseTools tools_def: Add CLANG9 tool chain to directly generate PE image

[Bob Feng]

Reviewed-by: Bob Feng <bob.c.feng@intel.com> 

-----Original Message-----
From: Gao, Liming 
Sent: Thursday, October 17, 2019 2:56 PM
To: devel@edk2.groups.io
Cc: Feng, Bob C <bob.c.feng@intel.com>
Subject: [Patch v3 02/11] BaseTools tools_def: Add CLANG9 tool chain to directly generate PE image

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603

Signed-off-by: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
---
 BaseTools/Conf/build_rule.template |  26 ++++++----  BaseTools/Conf/tools_def.template  | 102 +++++++++++++++++++++++++++++++++++++
 2 files changed, 118 insertions(+), 10 deletions(-)

diff --git a/BaseTools/Conf/build_rule.template b/BaseTools/Conf/build_rule.template
index db06d3a6b4..3a58ac8015 100755
--- a/BaseTools/Conf/build_rule.template
+++ b/BaseTools/Conf/build_rule.template
@@ -260,7 +260,7 @@
     <OutputFile>
         $(OUTPUT_DIR)(+)$(MODULE_NAME).lib
 
-    <Command.MSFT, Command.INTEL>
+    <Command.MSFT, Command.INTEL, Command.CLANGPE>
         "$(SLINK)" $(SLINK_FLAGS) /OUT:${dst} @$(OBJECT_FILES_LIST)
 
     <Command.GCC>
@@ -291,6 +291,9 @@
         "$(DLINK)" /OUT:${dst} $(DLINK_FLAGS) $(DLINK2_FLAGS) $(DLINK_SPATH) @$(STATIC_LIBRARY_FILES_LIST)
         "$(DLINK)" /OUT:${dst} $(DLINK_FLAGS) $(DLINK_SPATH) @$(STATIC_LIBRARY_FILES_LIST)
 
+    <Command.CLANGPE>
+        "$(DLINK)" /OUT:${dst} $(DLINK_FLAGS) $(DLINK_SPATH) 
+ @$(STATIC_LIBRARY_FILES_LIST) $(DLINK2_FLAGS)
+
     <Command.GCC>
         "$(DLINK)" -o ${dst} $(DLINK_FLAGS) -Wl,--start-group,@$(STATIC_LIBRARY_FILES_LIST),--end-group $(CC_FLAGS) $(DLINK2_FLAGS)
         "$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst} @@ -331,7 +334,7 @@
     <OutputFile>
         $(DEBUG_DIR)(+)$(MODULE_NAME)
 
-    <Command.MSFT, Command.INTEL>
+    <Command.MSFT, Command.INTEL, Command.CLANGPE>
         "$(DLINK)" $(DLINK_FLAGS) $(DLINK_SPATH) @$(STATIC_LIBRARY_FILES_LIST)
 
     <Command.GCC>
@@ -355,7 +358,7 @@
     <OutputFile>
         $(OUTPUT_DIR)(+)$(MODULE_NAME).efi
 
-    <Command.MSFT, Command.INTEL, Command.RVCT>
+    <Command.MSFT, Command.INTEL, Command.RVCT, Command.CLANGPE>
         "$(GENFW)" -e $(MODULE_TYPE) -o ${dst} ${src} $(GENFW_FLAGS)
         $(CP) ${dst} $(DEBUG_DIR)
         $(CP) ${dst} $(BIN_DIR)(+)$(MODULE_NAME_GUID).efi
@@ -460,9 +463,14 @@
 
     <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.CLANGPE>
+        "$(ASLCC)" -c -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj $(CC_FLAGS) $(ASLCC_FLAGS) $(INC) ${src}
+        "$(ASLDLINK)" /OUT:$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll $(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
+        "$(GENFW)" -o ${dst} -c 
+ $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll $(GENFW_FLAGS)
+
     <Command.XCODE>        
         "$(ASLCC)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj  $(ASLCC_FLAGS) $(INC) ${src}
         "$(ASLDLINK)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll $(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
@@ -622,21 +630,19 @@
     <InputFile>
         *.hpk
 
-    <OutputFile.MSFT, OutputFile.INTEL, OutputFile.GCC>
+    <OutputFile.MSFT, OutputFile.INTEL, OutputFile.GCC, 
+ OutputFile.CLANGPE>
         $(OUTPUT_DIR)(+)$(MODULE_NAME)hii.lib
 
     <OutputFile.XCODE, OutputFile.RVCT>
         $(OUTPUT_DIR)(+)$(MODULE_NAME)hii.rc
 
-    <Command.MSFT, Command.INTEL>
+    <Command.MSFT, Command.INTEL, Command.CLANGPE>
         "$(GENFW)" -o $(OUTPUT_DIR)(+)$(MODULE_NAME)hii.rc -g $(MODULE_GUID) --hiipackage $(HII_BINARY_PACKAGES) $(GENFW_FLAGS)
         "$(RC)" /Fo${dst} $(OUTPUT_DIR)(+)$(MODULE_NAME)hii.rc
 
     <Command.GCC>
         "$(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)
-        
-        
diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template
index fd6fca542d..b4bc27ab25 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -268,6 +268,15 @@ DEFINE DTC_BIN                 = ENV(DTC_PREFIX)dtc
 #                             Required to build platforms or ACPI tables:
 #                               Intel(r) ACPI Compiler from
 #                               https://acpica.org/downloads
+#   CLANG9   -Linux, Windows, Mac-  Requires:
+#                             Clang 9 or above from http://releases.llvm.org/
+#                        Optional:
+#                             Required to compile nasm source:
+#                               nasm compiler from
+#                               NASM -- http://www.nasm.us/
+#                             Required to build platforms or ACPI tables:
+#                               Intel(r) ACPI Compiler from
+#                               https://acpica.org/downloads
 #   VS2008x86   -win64-  Requires:
 #                             Microsoft Visual Studio 2008 (x86)
 #                             Microsoft Windows Server 2003 Driver Development Kit (Microsoft WINDDK) version 3790.1830
@@ -2698,6 +2707,99 @@ 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
 
+#######################################################################
+#############
+#
+# CLANG9 - This configuration is used to compile under 
+Windows/Linux/Mac to produce #  PE/COFF binaries using LLVM/Clang/LLD 
+with Link Time Optimization enabled # 
+####################################################################################
+*_CLANG9_*_*_FAMILY                = GCC
+*_CLANG9_*_*_BUILDRULEFAMILY       = CLANGPE
+*_CLANG9_*_MAKE_PATH               = ENV(CLANG_HOST_BIN)make
+*_CLANG9_*_*_DLL                   = ENV(CLANG9_DLL)
+*_CLANG9_*_ASL_PATH                = DEF(UNIX_IASL_BIN)
+
+*_CLANG9_*_APP_FLAGS               =
+*_CLANG9_*_ASL_FLAGS               = DEF(DEFAULT_WIN_ASL_FLAGS)
+*_CLANG9_*_ASL_OUTFLAGS            = DEF(DEFAULT_WIN_ASL_OUTFLAGS)
+*_CLANG9_*_ASLDLINK_FLAGS          = DEF(MSFT_ASLDLINK_FLAGS)
+
+DEFINE CLANG9_IA32_PREFIX          = ENV(CLANG9_BIN)
+DEFINE CLANG9_X64_PREFIX           = ENV(CLANG9_BIN)
+
+DEFINE CLANG9_IA32_TARGET          = -target i686-unknown-windows
+DEFINE CLANG9_X64_TARGET           = -target x86_64-unknown-windows
+
+DEFINE CLANG9_WARNING_OVERRIDES    = -Wno-parentheses-equality -Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare -Wno-empty-body -Wno-unused-const-variable -Wno-varargs -Wno-unknown-warning-option -Wno-microsoft-enum-forward-reference
+DEFINE CLANG9_ALL_CC_FLAGS         = DEF(GCC48_ALL_CC_FLAGS) DEF(CLANG9_WARNING_OVERRIDES) -fno-stack-protector -mms-bitfields -Wno-address -Wno-shift-negative-value -Wno-unknown-pragmas -Wno-incompatible-library-redeclaration -fno-asynchronous-unwind-tables -mno-implicit-float  -ftrap-function=undefined_behavior_has_been_optimized_away_by_clang -funsigned-char -fno-ms-extensions -Wno-null-dereference -fms-compatibility -mno-stack-arg-probe
+
+###########################
+# CLANG9 IA32 definitions
+###########################
+*_CLANG9_IA32_CC_PATH              = DEF(CLANG9_IA32_PREFIX)clang
+*_CLANG9_IA32_SLINK_PATH           = DEF(CLANG9_IA32_PREFIX)llvm-lib
+*_CLANG9_IA32_DLINK_PATH           = DEF(CLANG9_IA32_PREFIX)lld-link
+*_CLANG9_IA32_ASLDLINK_PATH        = DEF(CLANG9_IA32_PREFIX)lld-link
+*_CLANG9_IA32_ASM_PATH             = DEF(CLANG9_IA32_PREFIX)clang
+*_CLANG9_IA32_PP_PATH              = DEF(CLANG9_IA32_PREFIX)clang
+*_CLANG9_IA32_VFRPP_PATH           = DEF(CLANG9_IA32_PREFIX)clang
+*_CLANG9_IA32_ASLCC_PATH           = DEF(CLANG9_IA32_PREFIX)clang
+*_CLANG9_IA32_ASLPP_PATH           = DEF(CLANG9_IA32_PREFIX)clang
+*_CLANG9_IA32_RC_PATH              = DEF(CLANG9_IA32_PREFIX)llvm-rc
+
+*_CLANG9_IA32_ASLCC_FLAGS          = DEF(GCC_ASLCC_FLAGS) -m32 -fno-lto DEF(CLANG9_IA32_TARGET)
+*_CLANG9_IA32_ASM_FLAGS            = DEF(GCC5_ASM_FLAGS) -m32 -march=i386 DEF(CLANG9_IA32_TARGET)
+*_CLANG9_IA32_OBJCOPY_FLAGS        =
+*_CLANG9_IA32_NASM_FLAGS           = -f win32
+*_CLANG9_IA32_PP_FLAGS             = DEF(GCC_PP_FLAGS) DEF(CLANG9_IA32_TARGET)
+*_CLANG9_IA32_ASLPP_FLAGS          = DEF(GCC_ASLPP_FLAGS) DEF(CLANG9_IA32_TARGET)
+*_CLANG9_IA32_VFRPP_FLAGS          = DEF(GCC_VFRPP_FLAGS) DEF(CLANG9_IA32_TARGET)
+
+DEBUG_CLANG9_IA32_CC_FLAGS         = DEF(CLANG9_ALL_CC_FLAGS) -m32 -Oz -flto -march=i586 DEF(CLANG9_IA32_TARGET) -gcodeview
+DEBUG_CLANG9_IA32_DLINK_FLAGS      = /NOLOGO /NODEFAULTLIB /IGNORE:4001 /OPT:REF /OPT:ICF=10 /ALIGN:32 /FILEALIGN:32 /SECTION:.xdata,D /SECTION:.pdata,D /MACHINE:X86 /DLL /ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:0 /DEBUG:GHASH  /lldmap
+DEBUG_CLANG9_IA32_DLINK2_FLAGS     =
+
+RELEASE_CLANG9_IA32_CC_FLAGS       = DEF(CLANG9_ALL_CC_FLAGS) -m32 -Oz -flto -march=i586 DEF(CLANG9_IA32_TARGET)
+RELEASE_CLANG9_IA32_DLINK_FLAGS    = /NOLOGO /NODEFAULTLIB /IGNORE:4001 /IGNORE:4254 /OPT:REF /OPT:ICF=10 /ALIGN:32 /FILEALIGN:32 /SECTION:.xdata,D /SECTION:.pdata,D /MACHINE:X86 /DLL /ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:0 /MERGE:.rdata=.data  /lldmap
+RELEASE_CLANG9_IA32_DLINK2_FLAGS   =
+
+NOOPT_CLANG9_IA32_CC_FLAGS         = DEF(CLANG9_ALL_CC_FLAGS) -m32 -O0 -march=i586 DEF(CLANG9_IA32_TARGET) -gcodeview
+NOOPT_CLANG9_IA32_DLINK_FLAGS      = /NOLOGO /NODEFAULTLIB /IGNORE:4001 /OPT:REF /OPT:ICF=10 /ALIGN:32 /FILEALIGN:32 /SECTION:.xdata,D /SECTION:.pdata,D /MACHINE:X86 /DLL /ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:0 /DEBUG:GHASH  /lldmap
+NOOPT_CLANG9_IA32_DLINK2_FLAGS     =
+
+##########################
+# CLANGWIN X64 definitions
+##########################
+*_CLANG9_X64_CC_PATH              = DEF(CLANG9_X64_PREFIX)clang
+*_CLANG9_X64_SLINK_PATH           = DEF(CLANG9_X64_PREFIX)llvm-lib
+*_CLANG9_X64_DLINK_PATH           = DEF(CLANG9_X64_PREFIX)lld-link
+*_CLANG9_X64_ASLDLINK_PATH        = DEF(CLANG9_X64_PREFIX)lld-link
+*_CLANG9_X64_ASM_PATH             = DEF(CLANG9_X64_PREFIX)clang
+*_CLANG9_X64_PP_PATH              = DEF(CLANG9_X64_PREFIX)clang
+*_CLANG9_X64_VFRPP_PATH           = DEF(CLANG9_X64_PREFIX)clang
+*_CLANG9_X64_ASLCC_PATH           = DEF(CLANG9_X64_PREFIX)clang
+*_CLANG9_X64_ASLPP_PATH           = DEF(CLANG9_X64_PREFIX)clang
+*_CLANG9_X64_RC_PATH              = DEF(CLANG9_IA32_PREFIX)llvm-rc
+
+*_CLANG9_X64_ASLCC_FLAGS          = DEF(GCC_ASLCC_FLAGS) -m64 -fno-lto DEF(CLANG9_X64_TARGET)
+*_CLANG9_X64_ASM_FLAGS            = DEF(GCC5_ASM_FLAGS) -m64 DEF(CLANG9_X64_TARGET)
+*_CLANG9_X64_OBJCOPY_FLAGS        =
+*_CLANG9_X64_NASM_FLAGS           = -f win64
+*_CLANG9_X64_PP_FLAGS             = DEF(GCC_PP_FLAGS) DEF(CLANG9_X64_TARGET)
+*_CLANG9_X64_ASLPP_FLAGS          = DEF(GCC_ASLPP_FLAGS) DEF(CLANG9_X64_TARGET)
+*_CLANG9_X64_VFRPP_FLAGS          = DEF(GCC_VFRPP_FLAGS) DEF(CLANG9_X64_TARGET)
+
+DEBUG_CLANG9_X64_CC_FLAGS         = DEF(CLANG9_ALL_CC_FLAGS) -m64 "-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone -mcmodel=small -Oz -flto DEF(CLANG9_X64_TARGET) -gcodeview
+DEBUG_CLANG9_X64_DLINK_FLAGS      = /NOLOGO /NODEFAULTLIB /IGNORE:4001 /OPT:REF /OPT:ICF=10 /ALIGN:32 /FILEALIGN:32 /SECTION:.xdata,D /SECTION:.pdata,D /Machine:X64 /DLL /ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:0 /DEBUG:GHASH  /lldmap
+DEBUG_CLANG9_X64_DLINK2_FLAGS     =
+
+RELEASE_CLANG9_X64_CC_FLAGS       = DEF(CLANG9_ALL_CC_FLAGS) -m64 "-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone -mcmodel=small -Oz -flto DEF(CLANG9_X64_TARGET)
+RELEASE_CLANG9_X64_DLINK_FLAGS    = /NOLOGO /NODEFAULTLIB /IGNORE:4001 /IGNORE:4254 /OPT:REF /OPT:ICF=10 /ALIGN:32 /FILEALIGN:32 /SECTION:.xdata,D /SECTION:.pdata,D /Machine:X64 /DLL /ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:0 /MERGE:.rdata=.data  /lldmap
+RELEASE_CLANG9_X64_DLINK2_FLAGS   =
+
+NOOPT_CLANG9_X64_CC_FLAGS         = DEF(CLANG9_ALL_CC_FLAGS) -m64 "-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone -mcmodel=small -O0 DEF(CLANG9_X64_TARGET) -gcodeview
+NOOPT_CLANG9_X64_DLINK_FLAGS      = /NOLOGO /NODEFAULTLIB /IGNORE:4001 /OPT:REF /OPT:ICF=10 /ALIGN:32 /FILEALIGN:32 /SECTION:.xdata,D /SECTION:.pdata,D /Machine:X64 /DLL /ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:0 /DEBUG:GHASH  /lldmap
+NOOPT_CLANG9_X64_DLINK2_FLAGS     =
 
 
 #
--
2.13.0.windows.1

[Patch v3 03/11] BaseTools GenFw: Fix the issue to update the wrong size as SectionSize

[Liming Gao]

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
CLANG9 generated PE image exposes below two issues.
1. SectionSize is used to copy PE section data. It should be smaller than
section raw size.
2. The real data is required to be copied. So, copy the min size of
VirtualSize and SizeOfRawData.

Signed-off-by: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
---
 BaseTools/Source/C/GenFw/GenFw.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/C/GenFw/GenFw.c b/BaseTools/Source/C/GenFw/GenFw.c
index c99782b78e..8cab70ba4d 100644
--- a/BaseTools/Source/C/GenFw/GenFw.c
+++ b/BaseTools/Source/C/GenFw/GenFw.c
@@ -653,7 +653,11 @@ PeCoffConvertImageToXip (
     //
     // Make the size of raw data in section header alignment.
     //
-    SectionHeader->SizeOfRawData = (SectionHeader->Misc.VirtualSize + PeHdr->Pe32.OptionalHeader.FileAlignment - 1) & (~(PeHdr->Pe32.OptionalHeader.FileAlignment - 1));
+    SectionSize = (SectionHeader->Misc.VirtualSize + PeHdr->Pe32.OptionalHeader.FileAlignment - 1) & (~(PeHdr->Pe32.OptionalHeader.FileAlignment - 1));
+    if (SectionSize < SectionHeader->SizeOfRawData) {
+      SectionHeader->SizeOfRawData = SectionSize;
+    }
+
     SectionHeader->PointerToRawData = SectionHeader->VirtualAddress;
   }
 
@@ -999,7 +1003,7 @@ Returns:
     CopyMem (
       FileBuffer + SectionHeader->PointerToRawData,
       (VOID*) (UINTN) (ImageContext.ImageAddress + SectionHeader->VirtualAddress),
-      SectionHeader->SizeOfRawData
+      SectionHeader->SizeOfRawData < SectionHeader->Misc.VirtualSize ? SectionHeader->SizeOfRawData : SectionHeader->Misc.VirtualSize
       );
   }
 
-- 
2.13.0.windows.1

Re: [Patch v3 03/11] BaseTools GenFw: Fix the issue to update the wrong size as SectionSize

[Bob Feng]

Reviewed-by: Bob Feng <bob.c.feng@intel.com>

-----Original Message-----
From: Gao, Liming 
Sent: Thursday, October 17, 2019 2:56 PM
To: devel@edk2.groups.io
Cc: Feng, Bob C <bob.c.feng@intel.com>
Subject: [Patch v3 03/11] BaseTools GenFw: Fix the issue to update the wrong size as SectionSize

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
CLANG9 generated PE image exposes below two issues.
1. SectionSize is used to copy PE section data. It should be smaller than section raw size.
2. The real data is required to be copied. So, copy the min size of VirtualSize and SizeOfRawData.

Signed-off-by: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
---
 BaseTools/Source/C/GenFw/GenFw.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/C/GenFw/GenFw.c b/BaseTools/Source/C/GenFw/GenFw.c
index c99782b78e..8cab70ba4d 100644
--- a/BaseTools/Source/C/GenFw/GenFw.c
+++ b/BaseTools/Source/C/GenFw/GenFw.c
@@ -653,7 +653,11 @@ PeCoffConvertImageToXip (
     //
     // Make the size of raw data in section header alignment.
     //
-    SectionHeader->SizeOfRawData = (SectionHeader->Misc.VirtualSize + PeHdr->Pe32.OptionalHeader.FileAlignment - 1) & (~(PeHdr->Pe32.OptionalHeader.FileAlignment - 1));
+    SectionSize = (SectionHeader->Misc.VirtualSize + PeHdr->Pe32.OptionalHeader.FileAlignment - 1) & (~(PeHdr->Pe32.OptionalHeader.FileAlignment - 1));
+    if (SectionSize < SectionHeader->SizeOfRawData) {
+      SectionHeader->SizeOfRawData = SectionSize;
+    }
+
     SectionHeader->PointerToRawData = SectionHeader->VirtualAddress;
   }
 
@@ -999,7 +1003,7 @@ Returns:
     CopyMem (
       FileBuffer + SectionHeader->PointerToRawData,
       (VOID*) (UINTN) (ImageContext.ImageAddress + SectionHeader->VirtualAddress),
-      SectionHeader->SizeOfRawData
+      SectionHeader->SizeOfRawData < SectionHeader->Misc.VirtualSize ? 
+ SectionHeader->SizeOfRawData : SectionHeader->Misc.VirtualSize
       );
   }
 
--
2.13.0.windows.1

[Patch v3 04/11] MdePkg Base.h: Add definition for CLANG9 tool chain

[Liming Gao]

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
CLANG9 tool chain defines __clang__ macro only,
doesn't define __GNUC__ macro. But, it uses some same definitions with GCC.
So, update base definition for CLANG9 tool chain.

Signed-off-by: Liming Gao <liming.gao@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
---
 MdePkg/Include/Base.h               | 6 +++---
 MdePkg/Include/Ia32/ProcessorBind.h | 4 ++--
 MdePkg/Include/X64/ProcessorBind.h  | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
index d94b8a5f93..4680e64136 100644
--- a/MdePkg/Include/Base.h
+++ b/MdePkg/Include/Base.h
@@ -621,9 +621,9 @@ typedef char* VA_LIST;
 #define VA_END(Marker)                  (Marker = (VA_LIST) 0)
 #define VA_COPY(Dest, Start)            ((void)((Dest) = (Start)))
 
-#elif defined(__GNUC__)
+#elif defined(__GNUC__) || defined(__clang__)
 
-#if defined(MDE_CPU_X64) && !defined(NO_MSABI_VA_FUNCS)
+#if defined(MDE_CPU_X64) && !defined(NO_MSABI_VA_FUNCS) && !defined(__clang__)
 //
 // X64 only. Use MS ABI version of GCC built-in macros for variable argument lists.
 //
@@ -1274,7 +1274,7 @@ typedef UINTN RETURN_STATUS;
 
   **/
   #define RETURN_ADDRESS(L)     ((L == 0) ? _ReturnAddress() : (VOID *) 0)
-#elif defined(__GNUC__)
+#elif defined (__GNUC__) || defined (__clang__)
   void * __builtin_return_address (unsigned int level);
   /**
     Get the return address of the calling function.
diff --git a/MdePkg/Include/Ia32/ProcessorBind.h b/MdePkg/Include/Ia32/ProcessorBind.h
index 497c58b33b..fa4b7e8e98 100644
--- a/MdePkg/Include/Ia32/ProcessorBind.h
+++ b/MdePkg/Include/Ia32/ProcessorBind.h
@@ -281,7 +281,7 @@ typedef INT32   INTN;
   /// Microsoft* compiler specific method for EFIAPI calling convention.
   ///
   #define EFIAPI __cdecl
-#elif defined(__GNUC__)
+#elif defined(__GNUC__) || defined(__clang__)
   ///
   /// GCC specific method for EFIAPI calling convention.
   ///
@@ -294,7 +294,7 @@ typedef INT32   INTN;
   #define EFIAPI
 #endif
 
-#if defined(__GNUC__)
+#if defined(__GNUC__) || defined(__clang__)
   ///
   /// For GNU assembly code, .global or .globl can declare global symbols.
   /// Define this macro to unify the usage.
diff --git a/MdePkg/Include/X64/ProcessorBind.h b/MdePkg/Include/X64/ProcessorBind.h
index 6f65acd609..387e9c5c9c 100644
--- a/MdePkg/Include/X64/ProcessorBind.h
+++ b/MdePkg/Include/X64/ProcessorBind.h
@@ -313,7 +313,7 @@ typedef INT64   INTN;
   #define EFIAPI
 #endif
 
-#if defined(__GNUC__)
+#if defined(__GNUC__) || defined(__clang__)
   ///
   /// For GNU assembly code, .global or .globl can declare global symbols.
   /// Define this macro to unify the usage.
-- 
2.13.0.windows.1

Re: [edk2-devel] [Patch v3 04/11] MdePkg Base.h: Add definition for CLANG9 tool chain

[Michael D Kinney]

Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On
> Behalf Of Liming Gao
> Sent: Wednesday, October 16, 2019 11:56 PM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D <michael.d.kinney@intel.com>
> Subject: [edk2-devel] [Patch v3 04/11] MdePkg Base.h:
> Add definition for CLANG9 tool chain
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
> CLANG9 tool chain defines __clang__ macro only, doesn't
> define __GNUC__ macro. But, it uses some same
> definitions with GCC.
> So, update base definition for CLANG9 tool chain.
> 
> Signed-off-by: Liming Gao <liming.gao@intel.com>
> Cc: Michael Kinney <michael.d.kinney@intel.com>
> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
> ---
>  MdePkg/Include/Base.h               | 6 +++---
>  MdePkg/Include/Ia32/ProcessorBind.h | 4 ++--
> MdePkg/Include/X64/ProcessorBind.h  | 2 +-
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/MdePkg/Include/Base.h
> b/MdePkg/Include/Base.h index d94b8a5f93..4680e64136
> 100644
> --- a/MdePkg/Include/Base.h
> +++ b/MdePkg/Include/Base.h
> @@ -621,9 +621,9 @@ typedef char* VA_LIST;
>  #define VA_END(Marker)                  (Marker =
> (VA_LIST) 0)
>  #define VA_COPY(Dest, Start)            ((void)((Dest)
> = (Start)))
> 
> -#elif defined(__GNUC__)
> +#elif defined(__GNUC__) || defined(__clang__)
> 
> -#if defined(MDE_CPU_X64) &&
> !defined(NO_MSABI_VA_FUNCS)
> +#if defined(MDE_CPU_X64) &&
> !defined(NO_MSABI_VA_FUNCS) &&
> +!defined(__clang__)
>  //
>  // X64 only. Use MS ABI version of GCC built-in macros
> for variable argument lists.
>  //
> @@ -1274,7 +1274,7 @@ typedef UINTN RETURN_STATUS;
> 
>    **/
>    #define RETURN_ADDRESS(L)     ((L == 0) ?
> _ReturnAddress() : (VOID *) 0)
> -#elif defined(__GNUC__)
> +#elif defined (__GNUC__) || defined (__clang__)
>    void * __builtin_return_address (unsigned int
> level);
>    /**
>      Get the return address of the calling function.
> diff --git a/MdePkg/Include/Ia32/ProcessorBind.h
> b/MdePkg/Include/Ia32/ProcessorBind.h
> index 497c58b33b..fa4b7e8e98 100644
> --- a/MdePkg/Include/Ia32/ProcessorBind.h
> +++ b/MdePkg/Include/Ia32/ProcessorBind.h
> @@ -281,7 +281,7 @@ typedef INT32   INTN;
>    /// Microsoft* compiler specific method for EFIAPI
> calling convention.
>    ///
>    #define EFIAPI __cdecl
> -#elif defined(__GNUC__)
> +#elif defined(__GNUC__) || defined(__clang__)
>    ///
>    /// GCC specific method for EFIAPI calling
> convention.
>    ///
> @@ -294,7 +294,7 @@ typedef INT32   INTN;
>    #define EFIAPI
>  #endif
> 
> -#if defined(__GNUC__)
> +#if defined(__GNUC__) || defined(__clang__)
>    ///
>    /// For GNU assembly code, .global or .globl can
> declare global symbols.
>    /// Define this macro to unify the usage.
> diff --git a/MdePkg/Include/X64/ProcessorBind.h
> b/MdePkg/Include/X64/ProcessorBind.h
> index 6f65acd609..387e9c5c9c 100644
> --- a/MdePkg/Include/X64/ProcessorBind.h
> +++ b/MdePkg/Include/X64/ProcessorBind.h
> @@ -313,7 +313,7 @@ typedef INT64   INTN;
>    #define EFIAPI
>  #endif
> 
> -#if defined(__GNUC__)
> +#if defined(__GNUC__) || defined(__clang__)
>    ///
>    /// For GNU assembly code, .global or .globl can
> declare global symbols.
>    /// Define this macro to unify the usage.
> --
> 2.13.0.windows.1
> 
> 
> 

[Patch v3 05/11] MdePkg BaseIoLibIntrinsic: Remove __inline__ attribute for IO functions

[Liming Gao]

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
__inline__ has no functional difference effect with the GCC48 / GCC49 / GCC5
toolchains, but it breaks the build with CLANG9. Remove __inline__.

Signed-off-by: Liming Gao <liming.gao@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
---
 MdePkg/Library/BaseIoLibIntrinsic/IoLibGcc.c | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/MdePkg/Library/BaseIoLibIntrinsic/IoLibGcc.c b/MdePkg/Library/BaseIoLibIntrinsic/IoLibGcc.c
index 055f0a947e..b3a1a20256 100644
--- a/MdePkg/Library/BaseIoLibIntrinsic/IoLibGcc.c
+++ b/MdePkg/Library/BaseIoLibIntrinsic/IoLibGcc.c
@@ -32,7 +32,6 @@
   @return The value read.
 
 **/
-__inline__
 UINT8
 EFIAPI
 IoRead8 (
@@ -60,7 +59,6 @@ IoRead8 (
   @return The value written the I/O port.
 
 **/
-__inline__
 UINT8
 EFIAPI
 IoWrite8 (
@@ -87,7 +85,6 @@ IoWrite8 (
   @return The value read.
 
 **/
-__inline__
 UINT16
 EFIAPI
 IoRead16 (
@@ -117,7 +114,6 @@ IoRead16 (
   @return The value written the I/O port.
 
 **/
-__inline__
 UINT16
 EFIAPI
 IoWrite16 (
@@ -145,7 +141,6 @@ IoWrite16 (
   @return The value read.
 
 **/
-__inline__
 UINT32
 EFIAPI
 IoRead32 (
@@ -175,7 +170,6 @@ IoRead32 (
   @return The value written the I/O port.
 
 **/
-__inline__
 UINT32
 EFIAPI
 IoWrite32 (
-- 
2.13.0.windows.1

[Patch v3 06/11] MdeModulePkg LzmaCustomDecompressLib: Update macro to be same in CLANG tool

[Liming Gao]

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
Define the same macro in the different OS. It can make CLANG generate the same
image in the different host OS.

Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
---
 MdeModulePkg/Library/LzmaCustomDecompressLib/Sdk/C/7zTypes.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/LzmaCustomDecompressLib/Sdk/C/7zTypes.h b/MdeModulePkg/Library/LzmaCustomDecompressLib/Sdk/C/7zTypes.h
index ac06278002..c89b5c2433 100644
--- a/MdeModulePkg/Library/LzmaCustomDecompressLib/Sdk/C/7zTypes.h
+++ b/MdeModulePkg/Library/LzmaCustomDecompressLib/Sdk/C/7zTypes.h
@@ -118,7 +118,7 @@ typedef int Bool;
 #define MY_STD_CALL
 #endif
 
-#ifdef _MSC_VER
+#if defined(_MSC_VER) && !defined(__clang__)
 
 #if _MSC_VER >= 1300
 #define MY_NO_INLINE __declspec(noinline)
-- 
2.13.0.windows.1

[Patch v3 07/11] MdeModulePkg RegularExpressionDxe: Disable warning for CLANG9 tool chain

[Liming Gao]

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603

Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
---
 MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
index 883d5f1127..e9c885465d 100644
--- a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
+++ b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
@@ -107,6 +107,9 @@
   # Oniguruma: tag_end in parse_callout_of_name
   GCC:*_*_*_CC_FLAGS = -Wno-error=maybe-uninitialized
 
+  # Oniguruma: implicit conversion from 'UINTN' (aka 'unsigned long long') to 'long'
+  GCC:*_CLANG9_*_CC_FLAGS = -Wno-error=constant-conversion
+
   # Not add -Wno-error=maybe-uninitialized option for XCODE
   # XCODE doesn't know this option
   XCODE:*_*_*_CC_FLAGS =
-- 
2.13.0.windows.1

[Patch v3 08/11] CryptoPkg: Append options to make CLANG9 tool chain pass build

[Liming Gao]

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
Disable warning reported from CLANG9.

Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
---
 CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf    | 1 +
 CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf     | 1 +
 CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf | 1 +
 CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf     | 1 +
 CryptoPkg/Library/OpensslLib/OpensslLib.inf        | 1 +
 CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf  | 1 +
 6 files changed, 6 insertions(+)

diff --git a/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf b/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
index 8d4988e8c6..a98be2cd95 100644
--- a/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
+++ b/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
@@ -101,5 +101,6 @@
 
   GCC:*_CLANG35_*_CC_FLAGS = -std=c99
   GCC:*_CLANG38_*_CC_FLAGS = -std=c99
+  GCC:*_CLANG9_*_CC_FLAGS = -std=c99 -Wno-error=incompatible-pointer-types
 
   XCODE:*_*_*_CC_FLAGS = -std=c99
diff --git a/CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf b/CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf
index 3da8bd8480..7b07dd13d2 100644
--- a/CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf
+++ b/CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf
@@ -96,5 +96,6 @@
 
   GCC:*_CLANG35_*_CC_FLAGS = -std=c99
   GCC:*_CLANG38_*_CC_FLAGS = -std=c99
+  GCC:*_CLANG9_*_CC_FLAGS = -std=c99 -Wno-error=incompatible-pointer-types
 
   XCODE:*_*_*_CC_FLAGS = -std=c99
diff --git a/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf b/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
index 21a481eb77..d9e29ef660 100644
--- a/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
+++ b/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
@@ -107,5 +107,6 @@
 
   GCC:*_CLANG35_*_CC_FLAGS = -std=c99
   GCC:*_CLANG38_*_CC_FLAGS = -std=c99
+  GCC:*_CLANG9_*_CC_FLAGS = -std=c99 -Wno-error=incompatible-pointer-types
 
   XCODE:*_*_*_CC_FLAGS = -std=c99
diff --git a/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf b/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
index 7c187e21b3..b4faaf3f80 100644
--- a/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
+++ b/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
@@ -104,3 +104,4 @@
 
   GCC:*_CLANG35_*_CC_FLAGS = -std=c99
   GCC:*_CLANG38_*_CC_FLAGS = -std=c99
+  GCC:*_CLANG9_*_CC_FLAGS = -std=c99 -Wno-error=incompatible-pointer-types
diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
index 7432321fd4..b40d82783b 100644
--- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
+++ b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
@@ -662,6 +662,7 @@
   GCC:*_*_AARCH64_CC_FLAGS = $(OPENSSL_FLAGS) -Wno-error=maybe-uninitialized -Wno-format -Wno-error=unused-but-set-variable
   GCC:*_CLANG35_*_CC_FLAGS = -std=c99 -Wno-error=uninitialized
   GCC:*_CLANG38_*_CC_FLAGS = -std=c99 -Wno-error=uninitialized
+  GCC:*_CLANG9_*_CC_FLAGS = -std=c99 -Wno-error=uninitialized -Wno-error=incompatible-pointer-types -Wno-error=pointer-sign -Wno-error=implicit-function-declaration -Wno-error=ignored-pragma-optimize
 
   # suppress the following warnings in openssl so we don't break the build with warnings-as-errors:
   # 1295: Deprecated declaration <entity> - give arg types
diff --git a/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf b/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
index 8134b45eda..0a60196c8a 100644
--- a/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
+++ b/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
@@ -610,6 +610,7 @@
   GCC:*_*_AARCH64_CC_FLAGS = $(OPENSSL_FLAGS) -Wno-error=maybe-uninitialized -Wno-format -Wno-error=unused-but-set-variable
   GCC:*_CLANG35_*_CC_FLAGS = -std=c99 -Wno-error=uninitialized
   GCC:*_CLANG38_*_CC_FLAGS = -std=c99 -Wno-error=uninitialized
+  GCC:*_CLANG9_*_CC_FLAGS = -std=c99 -Wno-error=uninitialized -Wno-error=incompatible-pointer-types -Wno-error=pointer-sign -Wno-error=implicit-function-declaration -Wno-error=ignored-pragma-optimize
 
   # suppress the following warnings in openssl so we don't break the build with warnings-as-errors:
   # 1295: Deprecated declaration <entity> - give arg types
-- 
2.13.0.windows.1

[Patch v3 09/11] CryptoPkg IntrinsicLib: Make _fltused always be used

[Liming Gao]

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
With this change, global variable _fltused will not be removed by LTO

Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
---
 CryptoPkg/Library/IntrinsicLib/MemoryIntrinsics.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/CryptoPkg/Library/IntrinsicLib/MemoryIntrinsics.c b/CryptoPkg/Library/IntrinsicLib/MemoryIntrinsics.c
index 6e4d4a68cc..94fe341bec 100644
--- a/CryptoPkg/Library/IntrinsicLib/MemoryIntrinsics.c
+++ b/CryptoPkg/Library/IntrinsicLib/MemoryIntrinsics.c
@@ -2,7 +2,7 @@
   Intrinsic Memory Routines Wrapper Implementation for OpenSSL-based
   Cryptographic Library.
 
-Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.<BR>
+Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.<BR>
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -13,9 +13,15 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 
 typedef UINTN  size_t;
 
+#if defined(__GNUC__) || defined(__clang__)
+  #define GLOBAL_USED __attribute__((used))
+#else
+  #define GLOBAL_USED
+#endif
+
 /* OpenSSL will use floating point support, and C compiler produces the _fltused
    symbol by default. Simply define this symbol here to satisfy the linker. */
-int _fltused = 1;
+int  GLOBAL_USED _fltused = 1;
 
 /* Sets buffers to a specified character */
 void * memset (void *dest, int ch, size_t count)
-- 
2.13.0.windows.1

[Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

[Liming Gao]

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
1. Add WIN_SEC_BUILD macro check for CLANG9 tool chain
build -p EmulatorPkg\EmulatorPkg.dsc -a IA32 -DWIN_SEC_BUILD=TRUE -t CLANG9
build -p EmulatorPkg\EmulatorPkg.dsc -a X64 -DWIN_SEC_BUILD=TRUE -t CLANG9
2. Append CLANG CC and LINK flags to generate windows HOST.
3. Fix WinHost issue to call GetProcessAffinityMask() API.
   The input parameter should be UINTN pointer instead of UINT32 pointer.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Liming Gao <liming.gao@intel.com>
---
 EmulatorPkg/Win/Host/WinHost.c   | 6 +++---
 EmulatorPkg/EmulatorPkg.dsc      | 7 ++++++-
 EmulatorPkg/Win/Host/WinHost.inf | 6 ++++++
 3 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/EmulatorPkg/Win/Host/WinHost.c b/EmulatorPkg/Win/Host/WinHost.c
index 9aba3c8959..e40ce32548 100644
--- a/EmulatorPkg/Win/Host/WinHost.c
+++ b/EmulatorPkg/Win/Host/WinHost.c
@@ -356,7 +356,7 @@ Returns:
 INTN
 EFIAPI
 main (
-  IN  INTN  Argc,
+  IN  INT  Argc,
   IN  CHAR8 **Argv,
   IN  CHAR8 **Envp
   )
@@ -391,8 +391,8 @@ Returns:
   VOID                  *SecFile;
   CHAR16                *MemorySizeStr;
   CHAR16                *FirmwareVolumesStr;
-  UINT32                ProcessAffinityMask;
-  UINT32                SystemAffinityMask;
+  UINTN                 ProcessAffinityMask;
+  UINTN                 SystemAffinityMask;
   INT32                 LowBit;
 
   //
diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
index 20f1187713..72532f5daf 100644
--- a/EmulatorPkg/EmulatorPkg.dsc
+++ b/EmulatorPkg/EmulatorPkg.dsc
@@ -237,9 +237,10 @@
 
 [Components]
 !if "IA32" in $(ARCH) || "X64" in $(ARCH)
-  !if "MSFT" in $(FAMILY)
+  !if "MSFT" in $(FAMILY) || $(WIN_SEC_BUILD) == TRUE
     ##
     #  Emulator, OS WIN application
+    #  CLANG9 is cross OS tool chain. It depends on WIN_SEC_BUILD macro.
     ##
     EmulatorPkg/Win/Host/WinHost.inf
   !else
@@ -419,7 +420,11 @@
 
   MSFT:DEBUG_*_*_CC_FLAGS = /Od /Oy-
   MSFT:NOOPT_*_*_CC_FLAGS = /Od /Oy-
+  GCC:DEBUG_CLANG9_*_CC_FLAGS =-O0 -Wno-unused-command-line-argument -Wno-incompatible-pointer-types -Wno-enum-conversion -Wno-incompatible-pointer-types -Wno-sometimes-uninitialized -Wno-constant-conversion -Wno-main-return-type
 
   MSFT:*_*_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096 /SUBSYSTEM:CONSOLE
   MSFT:DEBUG_*_*_DLINK_FLAGS = /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
   MSFT:NOOPT_*_*_DLINK_FLAGS = /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
+  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096 /SUBSYSTEM:CONSOLE
+  GCC:DEBUG_CLANG9_*_DLINK_FLAGS = /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
+  GCC:NOOPT_CLANG9_*_DLINK_FLAGS = /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
diff --git a/EmulatorPkg/Win/Host/WinHost.inf b/EmulatorPkg/Win/Host/WinHost.inf
index 631d5a6470..1adca10d79 100644
--- a/EmulatorPkg/Win/Host/WinHost.inf
+++ b/EmulatorPkg/Win/Host/WinHost.inf
@@ -95,3 +95,9 @@
   MSFT:*_VS2017_X64_DLINK_FLAGS      = /LIBPATH:"%VCToolsInstallDir%lib\x64" /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64" /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64" /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP /OPT:REF /DEBUG /MACHINE:AMD64 /LTCG Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib Winmm.lib Advapi32.lib
   MSFT:*_*_X64_ASM_FLAGS            == /nologo /W3 /WX /c /Cx /Zd /W0 /Zi
   MSFT:*_*_X64_ASMLINK_FLAGS        == /link /nologo
+
+  GCC:*_CLANG9_X64_DLINK_FLAGS == /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000 /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"  /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64" /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64" /LIBPATH:"%VCToolsInstallDir%lib\x64"   /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:AMD64 Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib Winmm.lib Advapi32.lib /lldmap  /EXPORT:InitializeDriver=_ModuleEntryPoint
+  GCC:*_CLANG9_X64_CC_FLAGS == -m64 -g -fshort-wchar -fno-strict-aliasing -Wall -c -include AutoGen.h -D _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D UNICODE -D _CRT_SECURE_NO_DEPRECATE
+
+  GCC:*_CLANG9_IA32_DLINK_FLAGS == /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000 /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb" /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86" /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86" /LIBPATH:"%VCToolsInstallDir%ib\x86"   /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:I386 Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib Winmm.lib Advapi32.lib /lldmap  /EXPORT:InitializeDriver=_ModuleEntryPoint
+  GCC:*_CLANG9_IA32_CC_FLAGS == -m32 -g -fshort-wchar -fno-strict-aliasing -Wall -c -include AutoGen.h -D _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D UNICODE -D _CRT_SECURE_NO_DEPRECATE
-- 
2.13.0.windows.1

Re: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

[Ni, Ray]

Liming,
Emulator is using a generic SEC module. The host specific module is called "Host".
So I prefer to change the macro to "WIN_HOST_BUILD", with this change, Reviewed-by: Ray Ni <ray.ni@intel.com>

> -----Original Message-----
> From: Gao, Liming <liming.gao@intel.com>
> Sent: Thursday, October 17, 2019 2:56 PM
> To: devel@edk2.groups.io
> Cc: Justen, Jordan L <jordan.l.justen@intel.com>; Andrew Fish
> <afish@apple.com>; Ni, Ray <ray.ni@intel.com>
> Subject: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
> 1. Add WIN_SEC_BUILD macro check for CLANG9 tool chain build -p
> EmulatorPkg\EmulatorPkg.dsc -a IA32 -DWIN_SEC_BUILD=TRUE -t CLANG9
> build -p EmulatorPkg\EmulatorPkg.dsc -a X64 -DWIN_SEC_BUILD=TRUE -t
> CLANG9 2. Append CLANG CC and LINK flags to generate windows HOST.
> 3. Fix WinHost issue to call GetProcessAffinityMask() API.
>    The input parameter should be UINTN pointer instead of UINT32 pointer.
> 
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Andrew Fish <afish@apple.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Signed-off-by: Liming Gao <liming.gao@intel.com>
> ---
>  EmulatorPkg/Win/Host/WinHost.c   | 6 +++---
>  EmulatorPkg/EmulatorPkg.dsc      | 7 ++++++-
>  EmulatorPkg/Win/Host/WinHost.inf | 6 ++++++
>  3 files changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/EmulatorPkg/Win/Host/WinHost.c
> b/EmulatorPkg/Win/Host/WinHost.c index 9aba3c8959..e40ce32548 100644
> --- a/EmulatorPkg/Win/Host/WinHost.c
> +++ b/EmulatorPkg/Win/Host/WinHost.c
> @@ -356,7 +356,7 @@ Returns:
>  INTN
>  EFIAPI
>  main (
> -  IN  INTN  Argc,
> +  IN  INT  Argc,
>    IN  CHAR8 **Argv,
>    IN  CHAR8 **Envp
>    )
> @@ -391,8 +391,8 @@ Returns:
>    VOID                  *SecFile;
>    CHAR16                *MemorySizeStr;
>    CHAR16                *FirmwareVolumesStr;
> -  UINT32                ProcessAffinityMask;
> -  UINT32                SystemAffinityMask;
> +  UINTN                 ProcessAffinityMask;
> +  UINTN                 SystemAffinityMask;
>    INT32                 LowBit;
> 
>    //
> diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
> index 20f1187713..72532f5daf 100644
> --- a/EmulatorPkg/EmulatorPkg.dsc
> +++ b/EmulatorPkg/EmulatorPkg.dsc
> @@ -237,9 +237,10 @@
> 
>  [Components]
>  !if "IA32" in $(ARCH) || "X64" in $(ARCH)
> -  !if "MSFT" in $(FAMILY)
> +  !if "MSFT" in $(FAMILY) || $(WIN_SEC_BUILD) == TRUE
>      ##
>      #  Emulator, OS WIN application
> +    #  CLANG9 is cross OS tool chain. It depends on WIN_SEC_BUILD macro.
>      ##
>      EmulatorPkg/Win/Host/WinHost.inf
>    !else
> @@ -419,7 +420,11 @@
> 
>    MSFT:DEBUG_*_*_CC_FLAGS = /Od /Oy-
>    MSFT:NOOPT_*_*_CC_FLAGS = /Od /Oy-
> +  GCC:DEBUG_CLANG9_*_CC_FLAGS =-O0 -Wno-unused-command-line-
> argument
> + -Wno-incompatible-pointer-types -Wno-enum-conversion
> + -Wno-incompatible-pointer-types -Wno-sometimes-uninitialized
> + -Wno-constant-conversion -Wno-main-return-type
> 
>    MSFT:*_*_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
> /SUBSYSTEM:CONSOLE
>    MSFT:DEBUG_*_*_DLINK_FLAGS =
> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>    MSFT:NOOPT_*_*_DLINK_FLAGS =
> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> +  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
> /SUBSYSTEM:CONSOLE
> +  GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> + GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> diff --git a/EmulatorPkg/Win/Host/WinHost.inf
> b/EmulatorPkg/Win/Host/WinHost.inf
> index 631d5a6470..1adca10d79 100644
> --- a/EmulatorPkg/Win/Host/WinHost.inf
> +++ b/EmulatorPkg/Win/Host/WinHost.inf
> @@ -95,3 +95,9 @@
>    MSFT:*_VS2017_X64_DLINK_FLAGS      =
> /LIBPATH:"%VCToolsInstallDir%lib\x64"
> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
> /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP
> /OPT:REF /DEBUG /MACHINE:AMD64 /LTCG Kernel32.lib MSVCRTD.lib
> vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib Winmm.lib Advapi32.lib
>    MSFT:*_*_X64_ASM_FLAGS            == /nologo /W3 /WX /c /Cx /Zd /W0 /Zi
>    MSFT:*_*_X64_ASMLINK_FLAGS        == /link /nologo
> +
> +  GCC:*_CLANG9_X64_DLINK_FLAGS ==
> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
> /LIBPATH:"%VCToolsInstallDir%lib\x64"   /NOLOGO /SUBSYSTEM:CONSOLE
> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:AMD64
> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
> Winmm.lib Advapi32.lib /lldmap
> /EXPORT:InitializeDriver=_ModuleEntryPoint
> +  GCC:*_CLANG9_X64_CC_FLAGS == -m64 -g -fshort-wchar
> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D UNICODE
> -D
> + _CRT_SECURE_NO_DEPRECATE
> +
> +  GCC:*_CLANG9_IA32_DLINK_FLAGS ==
> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86"
> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86"
> /LIBPATH:"%VCToolsInstallDir%ib\x86"   /NOLOGO /SUBSYSTEM:CONSOLE
> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:I386
> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
> Winmm.lib Advapi32.lib /lldmap
> /EXPORT:InitializeDriver=_ModuleEntryPoint
> +  GCC:*_CLANG9_IA32_CC_FLAGS == -m32 -g -fshort-wchar
> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D UNICODE
> -D
> + _CRT_SECURE_NO_DEPRECATE
> --
> 2.13.0.windows.1

Re: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 7109 bytes --]

Ray,

Sorry I'm coming a little late to this and I'm confused. I have some questions?
1) Does CLANG9 imply CLANGPE? 
2) Does CLANGPE work on Linux and macOS? Can you pass the Windows style arguments to CLANGPE linker on Linux and macOS?
3) For the EmulatorPkg don't you have the extra requirement that compiler needs a standard C lib (or platform specific libs) to function?
	a) GCC:*_CLANG9_*_DLINK_FLAGS in EmulatorPkg.dsc seems to imply the Linux and macOS systems will have a Windows SKD dir and a lot of Windows DLLs? Does all that come when you install CLANG9 when you install it on Linux or macOS?

So I guess I'm asking is the linker really the same for CLANG9 on all systems? I guess the answer could be yes, but it seems the C lib for the Host App is still an App for that OS and is OS dependent? 

Sorry if I'm missing something fundamental and this is a dumb question. 

Thanks,

Andrew Fish



> On Oct 17, 2019, at 12:27 AM, Ni, Ray <ray.ni@intel.com> wrote:
> 
> Liming,
> Emulator is using a generic SEC module. The host specific module is called "Host".
> So I prefer to change the macro to "WIN_HOST_BUILD", with this change, Reviewed-by: Ray Ni <ray.ni@intel.com>
> 
>> -----Original Message-----
>> From: Gao, Liming <liming.gao@intel.com>
>> Sent: Thursday, October 17, 2019 2:56 PM
>> To: devel@edk2.groups.io
>> Cc: Justen, Jordan L <jordan.l.justen@intel.com>; Andrew Fish
>> <afish@apple.com>; Ni, Ray <ray.ni@intel.com>
>> Subject: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
>> 
>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
>> 1. Add WIN_SEC_BUILD macro check for CLANG9 tool chain build -p
>> EmulatorPkg\EmulatorPkg.dsc -a IA32 -DWIN_SEC_BUILD=TRUE -t CLANG9
>> build -p EmulatorPkg\EmulatorPkg.dsc -a X64 -DWIN_SEC_BUILD=TRUE -t
>> CLANG9 2. Append CLANG CC and LINK flags to generate windows HOST.
>> 3. Fix WinHost issue to call GetProcessAffinityMask() API.
>>   The input parameter should be UINTN pointer instead of UINT32 pointer.
>> 
>> Cc: Jordan Justen <jordan.l.justen@intel.com>
>> Cc: Andrew Fish <afish@apple.com>
>> Cc: Ray Ni <ray.ni@intel.com>
>> Signed-off-by: Liming Gao <liming.gao@intel.com>
>> ---
>> EmulatorPkg/Win/Host/WinHost.c   | 6 +++---
>> EmulatorPkg/EmulatorPkg.dsc      | 7 ++++++-
>> EmulatorPkg/Win/Host/WinHost.inf | 6 ++++++
>> 3 files changed, 15 insertions(+), 4 deletions(-)
>> 
>> diff --git a/EmulatorPkg/Win/Host/WinHost.c
>> b/EmulatorPkg/Win/Host/WinHost.c index 9aba3c8959..e40ce32548 100644
>> --- a/EmulatorPkg/Win/Host/WinHost.c
>> +++ b/EmulatorPkg/Win/Host/WinHost.c
>> @@ -356,7 +356,7 @@ Returns:
>> INTN
>> EFIAPI
>> main (
>> -  IN  INTN  Argc,
>> +  IN  INT  Argc,
>>   IN  CHAR8 **Argv,
>>   IN  CHAR8 **Envp
>>   )
>> @@ -391,8 +391,8 @@ Returns:
>>   VOID                  *SecFile;
>>   CHAR16                *MemorySizeStr;
>>   CHAR16                *FirmwareVolumesStr;
>> -  UINT32                ProcessAffinityMask;
>> -  UINT32                SystemAffinityMask;
>> +  UINTN                 ProcessAffinityMask;
>> +  UINTN                 SystemAffinityMask;
>>   INT32                 LowBit;
>> 
>>   //
>> diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
>> index 20f1187713..72532f5daf 100644
>> --- a/EmulatorPkg/EmulatorPkg.dsc
>> +++ b/EmulatorPkg/EmulatorPkg.dsc
>> @@ -237,9 +237,10 @@
>> 
>> [Components]
>> !if "IA32" in $(ARCH) || "X64" in $(ARCH)
>> -  !if "MSFT" in $(FAMILY)
>> +  !if "MSFT" in $(FAMILY) || $(WIN_SEC_BUILD) == TRUE
>>     ##
>>     #  Emulator, OS WIN application
>> +    #  CLANG9 is cross OS tool chain. It depends on WIN_SEC_BUILD macro.
>>     ##
>>     EmulatorPkg/Win/Host/WinHost.inf
>>   !else
>> @@ -419,7 +420,11 @@
>> 
>>   MSFT:DEBUG_*_*_CC_FLAGS = /Od /Oy-
>>   MSFT:NOOPT_*_*_CC_FLAGS = /Od /Oy-
>> +  GCC:DEBUG_CLANG9_*_CC_FLAGS =-O0 -Wno-unused-command-line-
>> argument
>> + -Wno-incompatible-pointer-types -Wno-enum-conversion
>> + -Wno-incompatible-pointer-types -Wno-sometimes-uninitialized
>> + -Wno-constant-conversion -Wno-main-return-type
>> 
>>   MSFT:*_*_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
>> /SUBSYSTEM:CONSOLE
>>   MSFT:DEBUG_*_*_DLINK_FLAGS =
>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>>   MSFT:NOOPT_*_*_DLINK_FLAGS =
>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>> +  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
>> /SUBSYSTEM:CONSOLE
>> +  GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
>> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>> + GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
>> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>> diff --git a/EmulatorPkg/Win/Host/WinHost.inf
>> b/EmulatorPkg/Win/Host/WinHost.inf
>> index 631d5a6470..1adca10d79 100644
>> --- a/EmulatorPkg/Win/Host/WinHost.inf
>> +++ b/EmulatorPkg/Win/Host/WinHost.inf
>> @@ -95,3 +95,9 @@
>>   MSFT:*_VS2017_X64_DLINK_FLAGS      =
>> /LIBPATH:"%VCToolsInstallDir%lib\x64"
>> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
>> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
>> /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP
>> /OPT:REF /DEBUG /MACHINE:AMD64 /LTCG Kernel32.lib MSVCRTD.lib
>> vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib Winmm.lib Advapi32.lib
>>   MSFT:*_*_X64_ASM_FLAGS            == /nologo /W3 /WX /c /Cx /Zd /W0 /Zi
>>   MSFT:*_*_X64_ASMLINK_FLAGS        == /link /nologo
>> +
>> +  GCC:*_CLANG9_X64_DLINK_FLAGS ==
>> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
>> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
>> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
>> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
>> /LIBPATH:"%VCToolsInstallDir%lib\x64"   /NOLOGO /SUBSYSTEM:CONSOLE
>> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:AMD64
>> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
>> Winmm.lib Advapi32.lib /lldmap
>> /EXPORT:InitializeDriver=_ModuleEntryPoint
>> +  GCC:*_CLANG9_X64_CC_FLAGS == -m64 -g -fshort-wchar
>> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
>> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D UNICODE
>> -D
>> + _CRT_SECURE_NO_DEPRECATE
>> +
>> +  GCC:*_CLANG9_IA32_DLINK_FLAGS ==
>> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
>> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
>> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86"
>> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86"
>> /LIBPATH:"%VCToolsInstallDir%ib\x86"   /NOLOGO /SUBSYSTEM:CONSOLE
>> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:I386
>> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
>> Winmm.lib Advapi32.lib /lldmap
>> /EXPORT:InitializeDriver=_ModuleEntryPoint
>> +  GCC:*_CLANG9_IA32_CC_FLAGS == -m32 -g -fshort-wchar
>> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
>> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D UNICODE
>> -D
>> + _CRT_SECURE_NO_DEPRECATE
>> --
>> 2.13.0.windows.1
> 


[-- Attachment #2: Type: text/html, Size: 12345 bytes --]

Re: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

[Liming Gao]

[-- Attachment #1: Type: text/plain, Size: 8752 bytes --]

Andrew:
 Here is the cover letter on CLANG9 introduction. https://edk2.groups.io/g/devel/message/49157


1)      Yes. CLANG9 tool chain is added to directly generate PE/COFF image (EFI image).
This tool chain uses LLVM clang C compiler and lld linker, generates PE/COFF
image and PDB compatible debug symbol format. Now, it supports IA32/X64 Archs.

LLVM clang C compiler and lld linker are the standalone tool set. They don't depend other lib to generate PE/COFF image.


2)      Yes. CLANG9 is the cross OS tool chain. It can work on Windows/Linux/Mac host OS.

LLVM LLD linker uses Windows style arguments. I verify CLANG9 for Ovmf3264 in Windows/Linux host OS.


3)     This patch enables WinHost in Windows. It doesn't enable UnixHost. Now, EmulatorPkg with CLANG9 only works on Windows Host.

This patch can make other modules pass build in Windows/Linux/Mac only if LLVM9 tool set is installed.

But, the generated image may not work on Linux/Mac. I agree below linker flags are specific to windows host.

So, I suggest to add the conditional statement of $(WIN_HOST_BUILD) == TRUE for them.

!if $(WIN_HOST_BUILD) == TRUE
  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096 /SUBSYSTEM:CONSOLE
  GCC:DEBUG_CLANG9_*_DLINK_FLAGS = /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
  GCC:NOOPT_CLANG9_*_DLINK_FLAGS = /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
!endif

Thanks
Liming
From: afish@apple.com <afish@apple.com>
Sent: Friday, October 18, 2019 1:15 AM
To: Ni, Ray <ray.ni@intel.com>
Cc: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io; Justen, Jordan L <jordan.l.justen@intel.com>
Subject: Re: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

Ray,

Sorry I'm coming a little late to this and I'm confused. I have some questions?
1) Does CLANG9 imply CLANGPE?
2) Does CLANGPE work on Linux and macOS? Can you pass the Windows style arguments to CLANGPE linker on Linux and macOS?
3) For the EmulatorPkg don't you have the extra requirement that compiler needs a standard C lib (or platform specific libs) to function?
       a) GCC:*_CLANG9_*_DLINK_FLAGS in EmulatorPkg.dsc seems to imply the Linux and macOS systems will have a Windows SKD dir and a lot of Windows DLLs? Does all that come when you install CLANG9 when you install it on Linux or macOS?


So I guess I'm asking is the linker really the same for CLANG9 on all systems? I guess the answer could be yes, but it seems the C lib for the Host App is still an App for that OS and is OS dependent?


Sorry if I'm missing something fundamental and this is a dumb question.


Thanks,


Andrew Fish





On Oct 17, 2019, at 12:27 AM, Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>> wrote:

Liming,
Emulator is using a generic SEC module. The host specific module is called "Host".
So I prefer to change the macro to "WIN_HOST_BUILD", with this change, Reviewed-by: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>


-----Original Message-----
From: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
Sent: Thursday, October 17, 2019 2:56 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Cc: Justen, Jordan L <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>; Andrew Fish
<afish@apple.com<mailto:afish@apple.com>>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
Subject: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
1. Add WIN_SEC_BUILD macro check for CLANG9 tool chain build -p
EmulatorPkg\EmulatorPkg.dsc -a IA32 -DWIN_SEC_BUILD=TRUE -t CLANG9
build -p EmulatorPkg\EmulatorPkg.dsc -a X64 -DWIN_SEC_BUILD=TRUE -t
CLANG9 2. Append CLANG CC and LINK flags to generate windows HOST.
3. Fix WinHost issue to call GetProcessAffinityMask() API.
  The input parameter should be UINTN pointer instead of UINT32 pointer.

Cc: Jordan Justen <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
Cc: Andrew Fish <afish@apple.com<mailto:afish@apple.com>>
Cc: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
Signed-off-by: Liming Gao <liming.gao@intel.com<mailto:liming.gao@intel.com>>
---
EmulatorPkg/Win/Host/WinHost.c   | 6 +++---
EmulatorPkg/EmulatorPkg.dsc      | 7 ++++++-
EmulatorPkg/Win/Host/WinHost.inf | 6 ++++++
3 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/EmulatorPkg/Win/Host/WinHost.c
b/EmulatorPkg/Win/Host/WinHost.c index 9aba3c8959..e40ce32548 100644
--- a/EmulatorPkg/Win/Host/WinHost.c
+++ b/EmulatorPkg/Win/Host/WinHost.c
@@ -356,7 +356,7 @@ Returns:
INTN
EFIAPI
main (
-  IN  INTN  Argc,
+  IN  INT  Argc,
  IN  CHAR8 **Argv,
  IN  CHAR8 **Envp
  )
@@ -391,8 +391,8 @@ Returns:
  VOID                  *SecFile;
  CHAR16                *MemorySizeStr;
  CHAR16                *FirmwareVolumesStr;
-  UINT32                ProcessAffinityMask;
-  UINT32                SystemAffinityMask;
+  UINTN                 ProcessAffinityMask;
+  UINTN                 SystemAffinityMask;
  INT32                 LowBit;

  //
diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
index 20f1187713..72532f5daf 100644
--- a/EmulatorPkg/EmulatorPkg.dsc
+++ b/EmulatorPkg/EmulatorPkg.dsc
@@ -237,9 +237,10 @@

[Components]
!if "IA32" in $(ARCH) || "X64" in $(ARCH)
-  !if "MSFT" in $(FAMILY)
+  !if "MSFT" in $(FAMILY) || $(WIN_SEC_BUILD) == TRUE
    ##
    #  Emulator, OS WIN application
+    #  CLANG9 is cross OS tool chain. It depends on WIN_SEC_BUILD macro.
    ##
    EmulatorPkg/Win/Host/WinHost.inf
  !else
@@ -419,7 +420,11 @@

  MSFT:DEBUG_*_*_CC_FLAGS = /Od /Oy-
  MSFT:NOOPT_*_*_CC_FLAGS = /Od /Oy-
+  GCC:DEBUG_CLANG9_*_CC_FLAGS =-O0 -Wno-unused-command-line-
argument
+ -Wno-incompatible-pointer-types -Wno-enum-conversion
+ -Wno-incompatible-pointer-types -Wno-sometimes-uninitialized
+ -Wno-constant-conversion -Wno-main-return-type

  MSFT:*_*_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
/SUBSYSTEM:CONSOLE
  MSFT:DEBUG_*_*_DLINK_FLAGS =
/EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
  MSFT:NOOPT_*_*_DLINK_FLAGS =
/EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
+  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
/SUBSYSTEM:CONSOLE
+  GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
+ /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
+ GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
+ /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
diff --git a/EmulatorPkg/Win/Host/WinHost.inf
b/EmulatorPkg/Win/Host/WinHost.inf
index 631d5a6470..1adca10d79 100644
--- a/EmulatorPkg/Win/Host/WinHost.inf
+++ b/EmulatorPkg/Win/Host/WinHost.inf
@@ -95,3 +95,9 @@
  MSFT:*_VS2017_X64_DLINK_FLAGS      =
/LIBPATH:"%VCToolsInstallDir%lib\x64"
/LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
/NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP
/OPT:REF /DEBUG /MACHINE:AMD64 /LTCG Kernel32.lib MSVCRTD.lib
vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib Winmm.lib Advapi32.lib
  MSFT:*_*_X64_ASM_FLAGS            == /nologo /W3 /WX /c /Cx /Zd /W0 /Zi
  MSFT:*_*_X64_ASMLINK_FLAGS        == /link /nologo
+
+  GCC:*_CLANG9_X64_DLINK_FLAGS ==
/out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
/pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
/LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
/LIBPATH:"%VCToolsInstallDir%lib\x64"   /NOLOGO /SUBSYSTEM:CONSOLE
/NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:AMD64
Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
Winmm.lib Advapi32.lib /lldmap
/EXPORT:InitializeDriver=_ModuleEntryPoint
+  GCC:*_CLANG9_X64_CC_FLAGS == -m64 -g -fshort-wchar
+ -fno-strict-aliasing -Wall -c -include AutoGen.h -D
+ _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D UNICODE
-D
+ _CRT_SECURE_NO_DEPRECATE
+
+  GCC:*_CLANG9_IA32_DLINK_FLAGS ==
/out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
/pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
/LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86"
/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86"
/LIBPATH:"%VCToolsInstallDir%ib\x86"   /NOLOGO /SUBSYSTEM:CONSOLE
/NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:I386
Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
Winmm.lib Advapi32.lib /lldmap
/EXPORT:InitializeDriver=_ModuleEntryPoint
+  GCC:*_CLANG9_IA32_CC_FLAGS == -m32 -g -fshort-wchar
+ -fno-strict-aliasing -Wall -c -include AutoGen.h -D
+ _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D UNICODE
-D
+ _CRT_SECURE_NO_DEPRECATE
--
2.13.0.windows.1



[-- Attachment #2: Type: text/html, Size: 21375 bytes --]

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 10608 bytes --]

Liming,

Sorry I missed this mail. Thanks for the info! I was doing some research into this too and now I think I finally understand. I think the name for the tool chain really confused me and we should think about changing the name. 

>From what I understand CLANG9 means produce PE/COFF directly and used the PDB debugging format. I see from the llvm site that the linker can produce PDB directly as you mention. This all makes sense to me now as LLVM tries to make it easy to be a drop in replacement for VC++ or GCC. So this tool chain is designed to be able to cross build a "Windows App" on a Linux or macOS. It also looks like the llvm debugger, lldb, is lagging in its support for PDB based debugging. 


Anyway I think Leif and I agree the toolchain name is very confusing. I'd rather see it called CLANG9_WIN or CLANG_PDB. 

> On Oct 18, 2019, at 7:27 AM, Liming Gao <liming.gao@intel.com> wrote:
> 
> Andrew:
>  Here is the cover letter on CLANG9 introduction. https://edk2.groups.io/g/devel/message/49157 <https://edk2.groups.io/g/devel/message/49157>
>
> 1)      Yes. CLANG9 tool chain is added to directly generate PE/COFF image (EFI image).
> This tool chain uses LLVM clang C compiler and lld linker, generates PE/COFF
> image and PDB compatible debug symbol format. Now, it supports IA32/X64 Archs.
> LLVM clang C compiler and lld linker are the standalone tool set. They don’t depend other lib to generate PE/COFF image.
>
> 2)      Yes. CLANG9 is the cross OS tool chain. It can work on Windows/Linux/Mac host OS.
> LLVM LLD linker uses Windows style arguments. I verify CLANG9 for Ovmf3264 in Windows/Linux host OS.
>

On Linux can you source level debug Ovmf? 

> 3)     This patch enables WinHost in Windows. It doesn’t enable UnixHost. Now, EmulatorPkg with CLANG9 only works on Windows Host.
> This patch can make other modules pass build in Windows/Linux/Mac only if LLVM9 tool set is installed.
> But, the generated image may not work on Linux/Mac. I agree below linker flags are specific to windows host.
> So, I suggest to add the conditional statement of $(WIN_HOST_BUILD) == TRUE for them.
>

For the EmulatorPkg the Host is a native App for that OS you build on, but it seems like CLANG9 is targeted to build Windows Apps. I'm not sure  but you might be able to override all the linker commands to build a native app, or just use the system linker for the Host?

I'm not sure how well debugging will work mixing PDB and DWARF symbol formats? 

Thanks,

Andrew Fish


> !if $(WIN_HOST_BUILD) == TRUE
>   GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096 /SUBSYSTEM:CONSOLE
>   GCC:DEBUG_CLANG9_*_DLINK_FLAGS = /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>   GCC:NOOPT_CLANG9_*_DLINK_FLAGS = /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> !endif
>
> Thanks
> Liming
>  <>From: afish@apple.com <afish@apple.com> 
> Sent: Friday, October 18, 2019 1:15 AM
> To: Ni, Ray <ray.ni@intel.com>
> Cc: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io; Justen, Jordan L <jordan.l.justen@intel.com>
> Subject: Re: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
>
> Ray,
>
> Sorry I'm coming a little late to this and I'm confused. I have some questions?
> 1) Does CLANG9 imply CLANGPE? 
> 2) Does CLANGPE work on Linux and macOS? Can you pass the Windows style arguments to CLANGPE linker on Linux and macOS?
> 3) For the EmulatorPkg don't you have the extra requirement that compiler needs a standard C lib (or platform specific libs) to function?
>        a) GCC:*_CLANG9_*_DLINK_FLAGS in EmulatorPkg.dsc seems to imply the Linux and macOS systems will have a Windows SKD dir and a lot of Windows DLLs? Does all that come when you install CLANG9 when you install it on Linux or macOS?
> 
> 
> So I guess I'm asking is the linker really the same for CLANG9 on all systems? I guess the answer could be yes, but it seems the C lib for the Host App is still an App for that OS and is OS dependent? 
> 
> 
> Sorry if I'm missing something fundamental and this is a dumb question. 
> 
> 
> Thanks,
> 
> 
> Andrew Fish
> 
>
>
> 
> 
> On Oct 17, 2019, at 12:27 AM, Ni, Ray <ray.ni@intel.com <mailto:ray.ni@intel.com>> wrote:
>
> Liming,
> Emulator is using a generic SEC module. The host specific module is called "Host".
> So I prefer to change the macro to "WIN_HOST_BUILD", with this change, Reviewed-by: Ray Ni <ray.ni@intel.com <mailto:ray.ni@intel.com>>
> 
> 
> -----Original Message-----
> From: Gao, Liming <liming.gao@intel.com <mailto:liming.gao@intel.com>>
> Sent: Thursday, October 17, 2019 2:56 PM
> To: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> Cc: Justen, Jordan L <jordan.l.justen@intel.com <mailto:jordan.l.justen@intel.com>>; Andrew Fish
> <afish@apple.com <mailto:afish@apple.com>>; Ni, Ray <ray.ni@intel.com <mailto:ray.ni@intel.com>>
> Subject: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603 <https://bugzilla.tianocore.org/show_bug.cgi?id=1603>
> 1. Add WIN_SEC_BUILD macro check for CLANG9 tool chain build -p
> EmulatorPkg\EmulatorPkg.dsc -a IA32 -DWIN_SEC_BUILD=TRUE -t CLANG9
> build -p EmulatorPkg\EmulatorPkg.dsc -a X64 -DWIN_SEC_BUILD=TRUE -t
> CLANG9 2. Append CLANG CC and LINK flags to generate windows HOST.
> 3. Fix WinHost issue to call GetProcessAffinityMask() API.
>   The input parameter should be UINTN pointer instead of UINT32 pointer.
> 
> Cc: Jordan Justen <jordan.l.justen@intel.com <mailto:jordan.l.justen@intel.com>>
> Cc: Andrew Fish <afish@apple.com <mailto:afish@apple.com>>
> Cc: Ray Ni <ray.ni@intel.com <mailto:ray.ni@intel.com>>
> Signed-off-by: Liming Gao <liming.gao@intel.com <mailto:liming.gao@intel.com>>
> ---
> EmulatorPkg/Win/Host/WinHost.c   | 6 +++---
> EmulatorPkg/EmulatorPkg.dsc      | 7 ++++++-
> EmulatorPkg/Win/Host/WinHost.inf | 6 ++++++
> 3 files changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/EmulatorPkg/Win/Host/WinHost.c
> b/EmulatorPkg/Win/Host/WinHost.c index 9aba3c8959..e40ce32548 100644
> --- a/EmulatorPkg/Win/Host/WinHost.c
> +++ b/EmulatorPkg/Win/Host/WinHost.c
> @@ -356,7 +356,7 @@ Returns:
> INTN
> EFIAPI
> main (
> -  IN  INTN  Argc,
> +  IN  INT  Argc,
>   IN  CHAR8 **Argv,
>   IN  CHAR8 **Envp
>   )
> @@ -391,8 +391,8 @@ Returns:
>   VOID                  *SecFile;
>   CHAR16                *MemorySizeStr;
>   CHAR16                *FirmwareVolumesStr;
> -  UINT32                ProcessAffinityMask;
> -  UINT32                SystemAffinityMask;
> +  UINTN                 ProcessAffinityMask;
> +  UINTN                 SystemAffinityMask;
>   INT32                 LowBit;
> 
>   //
> diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
> index 20f1187713..72532f5daf 100644
> --- a/EmulatorPkg/EmulatorPkg.dsc
> +++ b/EmulatorPkg/EmulatorPkg.dsc
> @@ -237,9 +237,10 @@
> 
> [Components]
> !if "IA32" in $(ARCH) || "X64" in $(ARCH)
> -  !if "MSFT" in $(FAMILY)
> +  !if "MSFT" in $(FAMILY) || $(WIN_SEC_BUILD) == TRUE
>     ##
>     #  Emulator, OS WIN application
> +    #  CLANG9 is cross OS tool chain. It depends on WIN_SEC_BUILD macro.
>     ##
>     EmulatorPkg/Win/Host/WinHost.inf
>   !else
> @@ -419,7 +420,11 @@
> 
>   MSFT:DEBUG_*_*_CC_FLAGS = /Od /Oy-
>   MSFT:NOOPT_*_*_CC_FLAGS = /Od /Oy-
> +  GCC:DEBUG_CLANG9_*_CC_FLAGS =-O0 -Wno-unused-command-line-
> argument
> + -Wno-incompatible-pointer-types -Wno-enum-conversion
> + -Wno-incompatible-pointer-types -Wno-sometimes-uninitialized
> + -Wno-constant-conversion -Wno-main-return-type
> 
>   MSFT:*_*_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
> /SUBSYSTEM:CONSOLE
>   MSFT:DEBUG_*_*_DLINK_FLAGS =
> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>   MSFT:NOOPT_*_*_DLINK_FLAGS =
> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> +  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
> /SUBSYSTEM:CONSOLE
> +  GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> + GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> diff --git a/EmulatorPkg/Win/Host/WinHost.inf
> b/EmulatorPkg/Win/Host/WinHost.inf
> index 631d5a6470..1adca10d79 100644
> --- a/EmulatorPkg/Win/Host/WinHost.inf
> +++ b/EmulatorPkg/Win/Host/WinHost.inf
> @@ -95,3 +95,9 @@
>   MSFT:*_VS2017_X64_DLINK_FLAGS      =
> /LIBPATH:"%VCToolsInstallDir%lib\x64"
> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
> /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP
> /OPT:REF /DEBUG /MACHINE:AMD64 /LTCG Kernel32.lib MSVCRTD.lib
> vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib Winmm.lib Advapi32.lib
>   MSFT:*_*_X64_ASM_FLAGS            == /nologo /W3 /WX /c /Cx /Zd /W0 /Zi
>   MSFT:*_*_X64_ASMLINK_FLAGS        == /link /nologo
> +
> +  GCC:*_CLANG9_X64_DLINK_FLAGS ==
> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
> /LIBPATH:"%VCToolsInstallDir%lib\x64"   /NOLOGO /SUBSYSTEM:CONSOLE
> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:AMD64
> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
> Winmm.lib Advapi32.lib /lldmap
> /EXPORT:InitializeDriver=_ModuleEntryPoint
> +  GCC:*_CLANG9_X64_CC_FLAGS == -m64 -g -fshort-wchar
> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D UNICODE
> -D
> + _CRT_SECURE_NO_DEPRECATE
> +
> +  GCC:*_CLANG9_IA32_DLINK_FLAGS ==
> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86"
> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86"
> /LIBPATH:"%VCToolsInstallDir%ib\x86"   /NOLOGO /SUBSYSTEM:CONSOLE
> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:I386
> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
> Winmm.lib Advapi32.lib /lldmap
> /EXPORT:InitializeDriver=_ModuleEntryPoint
> +  GCC:*_CLANG9_IA32_CC_FLAGS == -m32 -g -fshort-wchar
> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D UNICODE
> -D
> + _CRT_SECURE_NO_DEPRECATE
> --
> 2.13.0.windows.1
>
>
> 


[-- Attachment #2: Type: text/html, Size: 28240 bytes --]

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

[Liming Gao]

[-- Attachment #1: Type: text/plain, Size: 11564 bytes --]

Andrew:

  I prefer to keep short CLANG9 as the tool chain name. I add wiki page https://github.com/tianocore/tianocore.github.io/wiki/CLANG9-Tools-Chain to introduce it. And, we have CLANG38 tool chain. It generates ELF image and DWARF debug symbol format. It can work with LLVM 9.0 release. Current tool chain tag name includes compiler name and version. There is no specific info in the tool chain name. The developer can get the more tool chain information from wiki page.



  CLANG9 is designed to support Emulator for Windows host only. CLANG38 may be used for Emulator in Linux or Mac. I don’t try it before.

  CLANG9 goal is to align the same compiler in the different host development environment. It can replace VS or GCC compiler. On Windows Host, I verify VS debugger for the source level debug. On Linux host, I have not verified llvm debugger. I will investigate the debugger solution for OVMF in Linux host.

Thanks
Liming
From: afish@apple.com <afish@apple.com>
Sent: Saturday, October 26, 2019 2:45 AM
To: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>
Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>
Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

Liming,

Sorry I missed this mail. Thanks for the info! I was doing some research into this too and now I think I finally understand. I think the name for the tool chain really confused me and we should think about changing the name.

From what I understand CLANG9 means produce PE/COFF directly and used the PDB debugging format. I see from the llvm site that the linker can produce PDB directly as you mention. This all makes sense to me now as LLVM tries to make it easy to be a drop in replacement for VC++ or GCC. So this tool chain is designed to be able to cross build a "Windows App" on a Linux or macOS. It also looks like the llvm debugger, lldb, is lagging in its support for PDB based debugging.


Anyway I think Leif and I agree the toolchain name is very confusing. I'd rather see it called CLANG9_WIN or CLANG_PDB.


On Oct 18, 2019, at 7:27 AM, Liming Gao <liming.gao@intel.com<mailto:liming.gao@intel.com>> wrote:

Andrew:
 Here is the cover letter on CLANG9 introduction. https://edk2.groups.io/g/devel/message/49157

1)      Yes. CLANG9 tool chain is added to directly generate PE/COFF image (EFI image).
This tool chain uses LLVM clang C compiler and lld linker, generates PE/COFF
image and PDB compatible debug symbol format. Now, it supports IA32/X64 Archs.
LLVM clang C compiler and lld linker are the standalone tool set. They don’t depend other lib to generate PE/COFF image.

2)      Yes. CLANG9 is the cross OS tool chain. It can work on Windows/Linux/Mac host OS.
LLVM LLD linker uses Windows style arguments. I verify CLANG9 for Ovmf3264 in Windows/Linux host OS.


On Linux can you source level debug Ovmf?


3)     This patch enables WinHost in Windows. It doesn’t enable UnixHost. Now, EmulatorPkg with CLANG9 only works on Windows Host.
This patch can make other modules pass build in Windows/Linux/Mac only if LLVM9 tool set is installed.
But, the generated image may not work on Linux/Mac. I agree below linker flags are specific to windows host.
So, I suggest to add the conditional statement of $(WIN_HOST_BUILD) == TRUE for them.


For the EmulatorPkg the Host is a native App for that OS you build on, but it seems like CLANG9 is targeted to build Windows Apps. I'm not sure  but you might be able to override all the linker commands to build a native app, or just use the system linker for the Host?

I'm not sure how well debugging will work mixing PDB and DWARF symbol formats?

Thanks,

Andrew Fish



!if $(WIN_HOST_BUILD) == TRUE
  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096 /SUBSYSTEM:CONSOLE
  GCC:DEBUG_CLANG9_*_DLINK_FLAGS = /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
  GCC:NOOPT_CLANG9_*_DLINK_FLAGS = /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
!endif

Thanks
Liming
From: afish@apple.com<mailto:afish@apple.com> <afish@apple.com<mailto:afish@apple.com>>
Sent: Friday, October 18, 2019 1:15 AM
To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Justen, Jordan L <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
Subject: Re: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

Ray,

Sorry I'm coming a little late to this and I'm confused. I have some questions?
1) Does CLANG9 imply CLANGPE?
2) Does CLANGPE work on Linux and macOS? Can you pass the Windows style arguments to CLANGPE linker on Linux and macOS?
3) For the EmulatorPkg don't you have the extra requirement that compiler needs a standard C lib (or platform specific libs) to function?
       a) GCC:*_CLANG9_*_DLINK_FLAGS in EmulatorPkg.dsc seems to imply the Linux and macOS systems will have a Windows SKD dir and a lot of Windows DLLs? Does all that come when you install CLANG9 when you install it on Linux or macOS?



So I guess I'm asking is the linker really the same for CLANG9 on all systems? I guess the answer could be yes, but it seems the C lib for the Host App is still an App for that OS and is OS dependent?



Sorry if I'm missing something fundamental and this is a dumb question.



Thanks,



Andrew Fish







On Oct 17, 2019, at 12:27 AM, Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>> wrote:

Liming,
Emulator is using a generic SEC module. The host specific module is called "Host".
So I prefer to change the macro to "WIN_HOST_BUILD", with this change, Reviewed-by: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>



-----Original Message-----
From: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
Sent: Thursday, October 17, 2019 2:56 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Cc: Justen, Jordan L <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>; Andrew Fish
<afish@apple.com<mailto:afish@apple.com>>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
Subject: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
1. Add WIN_SEC_BUILD macro check for CLANG9 tool chain build -p
EmulatorPkg\EmulatorPkg.dsc -a IA32 -DWIN_SEC_BUILD=TRUE -t CLANG9
build -p EmulatorPkg\EmulatorPkg.dsc -a X64 -DWIN_SEC_BUILD=TRUE -t
CLANG9 2. Append CLANG CC and LINK flags to generate windows HOST.
3. Fix WinHost issue to call GetProcessAffinityMask() API.
  The input parameter should be UINTN pointer instead of UINT32 pointer.

Cc: Jordan Justen <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
Cc: Andrew Fish <afish@apple.com<mailto:afish@apple.com>>
Cc: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
Signed-off-by: Liming Gao <liming.gao@intel.com<mailto:liming.gao@intel.com>>
---
EmulatorPkg/Win/Host/WinHost.c   | 6 +++---
EmulatorPkg/EmulatorPkg.dsc      | 7 ++++++-
EmulatorPkg/Win/Host/WinHost.inf | 6 ++++++
3 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/EmulatorPkg/Win/Host/WinHost.c
b/EmulatorPkg/Win/Host/WinHost.c index 9aba3c8959..e40ce32548 100644
--- a/EmulatorPkg/Win/Host/WinHost.c
+++ b/EmulatorPkg/Win/Host/WinHost.c
@@ -356,7 +356,7 @@ Returns:
INTN
EFIAPI
main (
-  IN  INTN  Argc,
+  IN  INT  Argc,
  IN  CHAR8 **Argv,
  IN  CHAR8 **Envp
  )
@@ -391,8 +391,8 @@ Returns:
  VOID                  *SecFile;
  CHAR16                *MemorySizeStr;
  CHAR16                *FirmwareVolumesStr;
-  UINT32                ProcessAffinityMask;
-  UINT32                SystemAffinityMask;
+  UINTN                 ProcessAffinityMask;
+  UINTN                 SystemAffinityMask;
  INT32                 LowBit;

  //
diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
index 20f1187713..72532f5daf 100644
--- a/EmulatorPkg/EmulatorPkg.dsc
+++ b/EmulatorPkg/EmulatorPkg.dsc
@@ -237,9 +237,10 @@

[Components]
!if "IA32" in $(ARCH) || "X64" in $(ARCH)
-  !if "MSFT" in $(FAMILY)
+  !if "MSFT" in $(FAMILY) || $(WIN_SEC_BUILD) == TRUE
    ##
    #  Emulator, OS WIN application
+    #  CLANG9 is cross OS tool chain. It depends on WIN_SEC_BUILD macro.
    ##
    EmulatorPkg/Win/Host/WinHost.inf
  !else
@@ -419,7 +420,11 @@

  MSFT:DEBUG_*_*_CC_FLAGS = /Od /Oy-
  MSFT:NOOPT_*_*_CC_FLAGS = /Od /Oy-
+  GCC:DEBUG_CLANG9_*_CC_FLAGS =-O0 -Wno-unused-command-line-
argument
+ -Wno-incompatible-pointer-types -Wno-enum-conversion
+ -Wno-incompatible-pointer-types -Wno-sometimes-uninitialized
+ -Wno-constant-conversion -Wno-main-return-type

  MSFT:*_*_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
/SUBSYSTEM:CONSOLE
  MSFT:DEBUG_*_*_DLINK_FLAGS =
/EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
  MSFT:NOOPT_*_*_DLINK_FLAGS =
/EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
+  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
/SUBSYSTEM:CONSOLE
+  GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
+ /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
+ GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
+ /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
diff --git a/EmulatorPkg/Win/Host/WinHost.inf
b/EmulatorPkg/Win/Host/WinHost.inf
index 631d5a6470..1adca10d79 100644
--- a/EmulatorPkg/Win/Host/WinHost.inf
+++ b/EmulatorPkg/Win/Host/WinHost.inf
@@ -95,3 +95,9 @@
  MSFT:*_VS2017_X64_DLINK_FLAGS      =
/LIBPATH:"%VCToolsInstallDir%lib\x64"
/LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
/NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP
/OPT:REF /DEBUG /MACHINE:AMD64 /LTCG Kernel32.lib MSVCRTD.lib
vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib Winmm.lib Advapi32.lib
  MSFT:*_*_X64_ASM_FLAGS            == /nologo /W3 /WX /c /Cx /Zd /W0 /Zi
  MSFT:*_*_X64_ASMLINK_FLAGS        == /link /nologo
+
+  GCC:*_CLANG9_X64_DLINK_FLAGS ==
/out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
/pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
/LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
/LIBPATH:"%VCToolsInstallDir%lib\x64"   /NOLOGO /SUBSYSTEM:CONSOLE
/NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:AMD64
Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
Winmm.lib Advapi32.lib /lldmap
/EXPORT:InitializeDriver=_ModuleEntryPoint
+  GCC:*_CLANG9_X64_CC_FLAGS == -m64 -g -fshort-wchar
+ -fno-strict-aliasing -Wall -c -include AutoGen.h -D
+ _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D UNICODE
-D
+ _CRT_SECURE_NO_DEPRECATE
+
+  GCC:*_CLANG9_IA32_DLINK_FLAGS ==
/out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
/pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
/LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86"
/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86"
/LIBPATH:"%VCToolsInstallDir%ib\x86"   /NOLOGO /SUBSYSTEM:CONSOLE
/NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:I386
Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
Winmm.lib Advapi32.lib /lldmap
/EXPORT:InitializeDriver=_ModuleEntryPoint
+  GCC:*_CLANG9_IA32_CC_FLAGS == -m32 -g -fshort-wchar
+ -fno-strict-aliasing -Wall -c -include AutoGen.h -D
+ _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D UNICODE
-D
+ _CRT_SECURE_NO_DEPRECATE
--
2.13.0.windows.1





[-- Attachment #2: Type: text/html, Size: 32151 bytes --]

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

[Leif Lindholm]

Oops, sorry, missed this in search.

On Wed, Oct 30, 2019 at 03:43:44PM +0000, Liming Gao wrote:
> Andrew:
> 
>   I prefer to keep short CLANG9 as the tool chain name. I add wiki
>   page
>   https://github.com/tianocore/tianocore.github.io/wiki/CLANG9-Tools-Chain
>   to introduce it.

Why should users be expected to go and read documentation in order to
learn that fundamental and incompatible changes to output and debug
format has been made as part of what looks like a simple version bump?

>   And, we have CLANG38 tool chain. It generates ELF
>   image and DWARF debug symbol format. It can work with LLVM 9.0
>   release. Current tool chain tag name includes compiler name and
>   version. There is no specific info in the tool chain name. The
>   developer can get the more tool chain information from wiki page.

We aleady have the problem that people think they need to use GCC5 to
build EDK2 since that is the highest named GCC toolchain profile.

Let's not make this situation *worse* by setting up a multidimensional
feature matrix, based off random numerical values.

So say that we next have a pressing need to create a new toolchain
profile for clang 10, using the old ELF mechanism. Are you then
suggesting we set up a table on said wiki page where people have to go
and look up what the object and debug formats are for each CLANG##
toolchain profile?

And what if you then end up needing to do the same for the PDB
flavour?

>   CLANG9 is designed to support Emulator for Windows host only.

Which is why it makes no sense to name it as a successor of
CLANG38.

>   CLANG38 may be used for Emulator in Linux or Mac. I don’t
>   try it before.
> 
>   CLANG9 goal is to align the same compiler in the different host
>   development environment. It can replace VS or GCC compiler. On
>   Windows Host, I verify VS debugger for the source level debug. On
>   Linux host, I have not verified llvm debugger. I will investigate
>   the debugger solution for OVMF in Linux host.

We are not asking you to throw out this toolchain profile.

We are saying that since the functionality it provides is completely
unrelated to that of CLANG38, it should not be named in a way that
suggests it is merely a revision update.

/
    Leif

> Thanks
> Liming
> From: afish@apple.com <afish@apple.com>
> Sent: Saturday, October 26, 2019 2:45 AM
> To: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>
> Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>
> Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
> 
> Liming,
> 
> Sorry I missed this mail. Thanks for the info! I was doing some research into this too and now I think I finally understand. I think the name for the tool chain really confused me and we should think about changing the name.
> 
> From what I understand CLANG9 means produce PE/COFF directly and used the PDB debugging format. I see from the llvm site that the linker can produce PDB directly as you mention. This all makes sense to me now as LLVM tries to make it easy to be a drop in replacement for VC++ or GCC. So this tool chain is designed to be able to cross build a "Windows App" on a Linux or macOS. It also looks like the llvm debugger, lldb, is lagging in its support for PDB based debugging.
> 
> 
> Anyway I think Leif and I agree the toolchain name is very confusing. I'd rather see it called CLANG9_WIN or CLANG_PDB.
> 
> 
> On Oct 18, 2019, at 7:27 AM, Liming Gao <liming.gao@intel.com<mailto:liming.gao@intel.com>> wrote:
> 
> Andrew:
>  Here is the cover letter on CLANG9 introduction. https://edk2.groups.io/g/devel/message/49157
> 
> 1)      Yes. CLANG9 tool chain is added to directly generate PE/COFF image (EFI image).
> This tool chain uses LLVM clang C compiler and lld linker, generates PE/COFF
> image and PDB compatible debug symbol format. Now, it supports IA32/X64 Archs.
> LLVM clang C compiler and lld linker are the standalone tool set. They don’t depend other lib to generate PE/COFF image.
> 
> 2)      Yes. CLANG9 is the cross OS tool chain. It can work on Windows/Linux/Mac host OS.
> LLVM LLD linker uses Windows style arguments. I verify CLANG9 for Ovmf3264 in Windows/Linux host OS.
> 
> 
> On Linux can you source level debug Ovmf?
> 
> 
> 3)     This patch enables WinHost in Windows. It doesn’t enable UnixHost. Now, EmulatorPkg with CLANG9 only works on Windows Host.
> This patch can make other modules pass build in Windows/Linux/Mac only if LLVM9 tool set is installed.
> But, the generated image may not work on Linux/Mac. I agree below linker flags are specific to windows host.
> So, I suggest to add the conditional statement of $(WIN_HOST_BUILD) == TRUE for them.
> 
> 
> For the EmulatorPkg the Host is a native App for that OS you build on, but it seems like CLANG9 is targeted to build Windows Apps. I'm not sure  but you might be able to override all the linker commands to build a native app, or just use the system linker for the Host?
> 
> I'm not sure how well debugging will work mixing PDB and DWARF symbol formats?
> 
> Thanks,
> 
> Andrew Fish
> 
> 
> 
> !if $(WIN_HOST_BUILD) == TRUE
>   GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096 /SUBSYSTEM:CONSOLE
>   GCC:DEBUG_CLANG9_*_DLINK_FLAGS = /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>   GCC:NOOPT_CLANG9_*_DLINK_FLAGS = /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> !endif
> 
> Thanks
> Liming
> From: afish@apple.com<mailto:afish@apple.com> <afish@apple.com<mailto:afish@apple.com>>
> Sent: Friday, October 18, 2019 1:15 AM
> To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Justen, Jordan L <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
> Subject: Re: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
> 
> Ray,
> 
> Sorry I'm coming a little late to this and I'm confused. I have some questions?
> 1) Does CLANG9 imply CLANGPE?
> 2) Does CLANGPE work on Linux and macOS? Can you pass the Windows style arguments to CLANGPE linker on Linux and macOS?
> 3) For the EmulatorPkg don't you have the extra requirement that compiler needs a standard C lib (or platform specific libs) to function?
>        a) GCC:*_CLANG9_*_DLINK_FLAGS in EmulatorPkg.dsc seems to imply the Linux and macOS systems will have a Windows SKD dir and a lot of Windows DLLs? Does all that come when you install CLANG9 when you install it on Linux or macOS?
> 
> 
> 
> So I guess I'm asking is the linker really the same for CLANG9 on all systems? I guess the answer could be yes, but it seems the C lib for the Host App is still an App for that OS and is OS dependent?
> 
> 
> 
> Sorry if I'm missing something fundamental and this is a dumb question.
> 
> 
> 
> Thanks,
> 
> 
> 
> Andrew Fish
> 
> 
> 
> 
> 
> 
> 
> On Oct 17, 2019, at 12:27 AM, Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>> wrote:
> 
> Liming,
> Emulator is using a generic SEC module. The host specific module is called "Host".
> So I prefer to change the macro to "WIN_HOST_BUILD", with this change, Reviewed-by: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> 
> 
> 
> -----Original Message-----
> From: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> Sent: Thursday, October 17, 2019 2:56 PM
> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> Cc: Justen, Jordan L <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>; Andrew Fish
> <afish@apple.com<mailto:afish@apple.com>>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> Subject: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
> 1. Add WIN_SEC_BUILD macro check for CLANG9 tool chain build -p
> EmulatorPkg\EmulatorPkg.dsc -a IA32 -DWIN_SEC_BUILD=TRUE -t CLANG9
> build -p EmulatorPkg\EmulatorPkg.dsc -a X64 -DWIN_SEC_BUILD=TRUE -t
> CLANG9 2. Append CLANG CC and LINK flags to generate windows HOST.
> 3. Fix WinHost issue to call GetProcessAffinityMask() API.
>   The input parameter should be UINTN pointer instead of UINT32 pointer.
> 
> Cc: Jordan Justen <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
> Cc: Andrew Fish <afish@apple.com<mailto:afish@apple.com>>
> Cc: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> Signed-off-by: Liming Gao <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> ---
> EmulatorPkg/Win/Host/WinHost.c   | 6 +++---
> EmulatorPkg/EmulatorPkg.dsc      | 7 ++++++-
> EmulatorPkg/Win/Host/WinHost.inf | 6 ++++++
> 3 files changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/EmulatorPkg/Win/Host/WinHost.c
> b/EmulatorPkg/Win/Host/WinHost.c index 9aba3c8959..e40ce32548 100644
> --- a/EmulatorPkg/Win/Host/WinHost.c
> +++ b/EmulatorPkg/Win/Host/WinHost.c
> @@ -356,7 +356,7 @@ Returns:
> INTN
> EFIAPI
> main (
> -  IN  INTN  Argc,
> +  IN  INT  Argc,
>   IN  CHAR8 **Argv,
>   IN  CHAR8 **Envp
>   )
> @@ -391,8 +391,8 @@ Returns:
>   VOID                  *SecFile;
>   CHAR16                *MemorySizeStr;
>   CHAR16                *FirmwareVolumesStr;
> -  UINT32                ProcessAffinityMask;
> -  UINT32                SystemAffinityMask;
> +  UINTN                 ProcessAffinityMask;
> +  UINTN                 SystemAffinityMask;
>   INT32                 LowBit;
> 
>   //
> diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
> index 20f1187713..72532f5daf 100644
> --- a/EmulatorPkg/EmulatorPkg.dsc
> +++ b/EmulatorPkg/EmulatorPkg.dsc
> @@ -237,9 +237,10 @@
> 
> [Components]
> !if "IA32" in $(ARCH) || "X64" in $(ARCH)
> -  !if "MSFT" in $(FAMILY)
> +  !if "MSFT" in $(FAMILY) || $(WIN_SEC_BUILD) == TRUE
>     ##
>     #  Emulator, OS WIN application
> +    #  CLANG9 is cross OS tool chain. It depends on WIN_SEC_BUILD macro.
>     ##
>     EmulatorPkg/Win/Host/WinHost.inf
>   !else
> @@ -419,7 +420,11 @@
> 
>   MSFT:DEBUG_*_*_CC_FLAGS = /Od /Oy-
>   MSFT:NOOPT_*_*_CC_FLAGS = /Od /Oy-
> +  GCC:DEBUG_CLANG9_*_CC_FLAGS =-O0 -Wno-unused-command-line-
> argument
> + -Wno-incompatible-pointer-types -Wno-enum-conversion
> + -Wno-incompatible-pointer-types -Wno-sometimes-uninitialized
> + -Wno-constant-conversion -Wno-main-return-type
> 
>   MSFT:*_*_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
> /SUBSYSTEM:CONSOLE
>   MSFT:DEBUG_*_*_DLINK_FLAGS =
> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>   MSFT:NOOPT_*_*_DLINK_FLAGS =
> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> +  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
> /SUBSYSTEM:CONSOLE
> +  GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> + GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> diff --git a/EmulatorPkg/Win/Host/WinHost.inf
> b/EmulatorPkg/Win/Host/WinHost.inf
> index 631d5a6470..1adca10d79 100644
> --- a/EmulatorPkg/Win/Host/WinHost.inf
> +++ b/EmulatorPkg/Win/Host/WinHost.inf
> @@ -95,3 +95,9 @@
>   MSFT:*_VS2017_X64_DLINK_FLAGS      =
> /LIBPATH:"%VCToolsInstallDir%lib\x64"
> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
> /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP
> /OPT:REF /DEBUG /MACHINE:AMD64 /LTCG Kernel32.lib MSVCRTD.lib
> vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib Winmm.lib Advapi32.lib
>   MSFT:*_*_X64_ASM_FLAGS            == /nologo /W3 /WX /c /Cx /Zd /W0 /Zi
>   MSFT:*_*_X64_ASMLINK_FLAGS        == /link /nologo
> +
> +  GCC:*_CLANG9_X64_DLINK_FLAGS ==
> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
> /LIBPATH:"%VCToolsInstallDir%lib\x64"   /NOLOGO /SUBSYSTEM:CONSOLE
> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:AMD64
> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
> Winmm.lib Advapi32.lib /lldmap
> /EXPORT:InitializeDriver=_ModuleEntryPoint
> +  GCC:*_CLANG9_X64_CC_FLAGS == -m64 -g -fshort-wchar
> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D UNICODE
> -D
> + _CRT_SECURE_NO_DEPRECATE
> +
> +  GCC:*_CLANG9_IA32_DLINK_FLAGS ==
> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86"
> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86"
> /LIBPATH:"%VCToolsInstallDir%ib\x86"   /NOLOGO /SUBSYSTEM:CONSOLE
> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:I386
> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
> Winmm.lib Advapi32.lib /lldmap
> /EXPORT:InitializeDriver=_ModuleEntryPoint
> +  GCC:*_CLANG9_IA32_CC_FLAGS == -m32 -g -fshort-wchar
> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D UNICODE
> -D
> + _CRT_SECURE_NO_DEPRECATE
> --
> 2.13.0.windows.1
> 
> 
> 
> 
> 
> 
> 

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

[Andrew Fish]

Leif,

I think I proposed CLANG_PDB or CLANG_PECOFF. I seem to like CLANG_PDB as assuming the PDE debugging experience is awesome/exists on Linux and macOS is not a given. 

Thanks,

Andrew Fish

> On Nov 7, 2019, at 11:19 AM, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> 
> Oops, sorry, missed this in search.
> 
> On Wed, Oct 30, 2019 at 03:43:44PM +0000, Liming Gao wrote:
>> Andrew:
>> 
>>  I prefer to keep short CLANG9 as the tool chain name. I add wiki
>>  page
>>  https://github.com/tianocore/tianocore.github.io/wiki/CLANG9-Tools-Chain
>>  to introduce it.
> 
> Why should users be expected to go and read documentation in order to
> learn that fundamental and incompatible changes to output and debug
> format has been made as part of what looks like a simple version bump?
> 
>>  And, we have CLANG38 tool chain. It generates ELF
>>  image and DWARF debug symbol format. It can work with LLVM 9.0
>>  release. Current tool chain tag name includes compiler name and
>>  version. There is no specific info in the tool chain name. The
>>  developer can get the more tool chain information from wiki page.
> 
> We aleady have the problem that people think they need to use GCC5 to
> build EDK2 since that is the highest named GCC toolchain profile.
> 
> Let's not make this situation *worse* by setting up a multidimensional
> feature matrix, based off random numerical values.
> 
> So say that we next have a pressing need to create a new toolchain
> profile for clang 10, using the old ELF mechanism. Are you then
> suggesting we set up a table on said wiki page where people have to go
> and look up what the object and debug formats are for each CLANG##
> toolchain profile?
> 
> And what if you then end up needing to do the same for the PDB
> flavour?
> 
>>  CLANG9 is designed to support Emulator for Windows host only.
> 
> Which is why it makes no sense to name it as a successor of
> CLANG38.
> 
>>  CLANG38 may be used for Emulator in Linux or Mac. I don’t
>>  try it before.
>> 
>>  CLANG9 goal is to align the same compiler in the different host
>>  development environment. It can replace VS or GCC compiler. On
>>  Windows Host, I verify VS debugger for the source level debug. On
>>  Linux host, I have not verified llvm debugger. I will investigate
>>  the debugger solution for OVMF in Linux host.
> 
> We are not asking you to throw out this toolchain profile.
> 
> We are saying that since the functionality it provides is completely
> unrelated to that of CLANG38, it should not be named in a way that
> suggests it is merely a revision update.
> 
> /
>    Leif
> 
>> Thanks
>> Liming
>> From: afish@apple.com <afish@apple.com>
>> Sent: Saturday, October 26, 2019 2:45 AM
>> To: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>
>> Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>
>> Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
>> 
>> Liming,
>> 
>> Sorry I missed this mail. Thanks for the info! I was doing some research into this too and now I think I finally understand. I think the name for the tool chain really confused me and we should think about changing the name.
>> 
>> From what I understand CLANG9 means produce PE/COFF directly and used the PDB debugging format. I see from the llvm site that the linker can produce PDB directly as you mention. This all makes sense to me now as LLVM tries to make it easy to be a drop in replacement for VC++ or GCC. So this tool chain is designed to be able to cross build a "Windows App" on a Linux or macOS. It also looks like the llvm debugger, lldb, is lagging in its support for PDB based debugging.
>> 
>> 
>> Anyway I think Leif and I agree the toolchain name is very confusing. I'd rather see it called CLANG9_WIN or CLANG_PDB.
>> 
>> 
>> On Oct 18, 2019, at 7:27 AM, Liming Gao <liming.gao@intel.com<mailto:liming.gao@intel.com>> wrote:
>> 
>> Andrew:
>> Here is the cover letter on CLANG9 introduction. https://edk2.groups.io/g/devel/message/49157
>> 
>> 1)      Yes. CLANG9 tool chain is added to directly generate PE/COFF image (EFI image).
>> This tool chain uses LLVM clang C compiler and lld linker, generates PE/COFF
>> image and PDB compatible debug symbol format. Now, it supports IA32/X64 Archs.
>> LLVM clang C compiler and lld linker are the standalone tool set. They don’t depend other lib to generate PE/COFF image.
>> 
>> 2)      Yes. CLANG9 is the cross OS tool chain. It can work on Windows/Linux/Mac host OS.
>> LLVM LLD linker uses Windows style arguments. I verify CLANG9 for Ovmf3264 in Windows/Linux host OS.
>> 
>> 
>> On Linux can you source level debug Ovmf?
>> 
>> 
>> 3)     This patch enables WinHost in Windows. It doesn’t enable UnixHost. Now, EmulatorPkg with CLANG9 only works on Windows Host.
>> This patch can make other modules pass build in Windows/Linux/Mac only if LLVM9 tool set is installed.
>> But, the generated image may not work on Linux/Mac. I agree below linker flags are specific to windows host.
>> So, I suggest to add the conditional statement of $(WIN_HOST_BUILD) == TRUE for them.
>> 
>> 
>> For the EmulatorPkg the Host is a native App for that OS you build on, but it seems like CLANG9 is targeted to build Windows Apps. I'm not sure  but you might be able to override all the linker commands to build a native app, or just use the system linker for the Host?
>> 
>> I'm not sure how well debugging will work mixing PDB and DWARF symbol formats?
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>> 
>> 
>> !if $(WIN_HOST_BUILD) == TRUE
>>  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096 /SUBSYSTEM:CONSOLE
>>  GCC:DEBUG_CLANG9_*_DLINK_FLAGS = /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>>  GCC:NOOPT_CLANG9_*_DLINK_FLAGS = /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>> !endif
>> 
>> Thanks
>> Liming
>> From: afish@apple.com<mailto:afish@apple.com> <afish@apple.com<mailto:afish@apple.com>>
>> Sent: Friday, October 18, 2019 1:15 AM
>> To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
>> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Justen, Jordan L <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
>> Subject: Re: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
>> 
>> Ray,
>> 
>> Sorry I'm coming a little late to this and I'm confused. I have some questions?
>> 1) Does CLANG9 imply CLANGPE?
>> 2) Does CLANGPE work on Linux and macOS? Can you pass the Windows style arguments to CLANGPE linker on Linux and macOS?
>> 3) For the EmulatorPkg don't you have the extra requirement that compiler needs a standard C lib (or platform specific libs) to function?
>>       a) GCC:*_CLANG9_*_DLINK_FLAGS in EmulatorPkg.dsc seems to imply the Linux and macOS systems will have a Windows SKD dir and a lot of Windows DLLs? Does all that come when you install CLANG9 when you install it on Linux or macOS?
>> 
>> 
>> 
>> So I guess I'm asking is the linker really the same for CLANG9 on all systems? I guess the answer could be yes, but it seems the C lib for the Host App is still an App for that OS and is OS dependent?
>> 
>> 
>> 
>> Sorry if I'm missing something fundamental and this is a dumb question.
>> 
>> 
>> 
>> Thanks,
>> 
>> 
>> 
>> Andrew Fish
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Oct 17, 2019, at 12:27 AM, Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>> wrote:
>> 
>> Liming,
>> Emulator is using a generic SEC module. The host specific module is called "Host".
>> So I prefer to change the macro to "WIN_HOST_BUILD", with this change, Reviewed-by: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
>> 
>> 
>> 
>> -----Original Message-----
>> From: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
>> Sent: Thursday, October 17, 2019 2:56 PM
>> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
>> Cc: Justen, Jordan L <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>; Andrew Fish
>> <afish@apple.com<mailto:afish@apple.com>>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
>> Subject: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
>> 
>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
>> 1. Add WIN_SEC_BUILD macro check for CLANG9 tool chain build -p
>> EmulatorPkg\EmulatorPkg.dsc -a IA32 -DWIN_SEC_BUILD=TRUE -t CLANG9
>> build -p EmulatorPkg\EmulatorPkg.dsc -a X64 -DWIN_SEC_BUILD=TRUE -t
>> CLANG9 2. Append CLANG CC and LINK flags to generate windows HOST.
>> 3. Fix WinHost issue to call GetProcessAffinityMask() API.
>>  The input parameter should be UINTN pointer instead of UINT32 pointer.
>> 
>> Cc: Jordan Justen <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
>> Cc: Andrew Fish <afish@apple.com<mailto:afish@apple.com>>
>> Cc: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
>> Signed-off-by: Liming Gao <liming.gao@intel.com<mailto:liming.gao@intel.com>>
>> ---
>> EmulatorPkg/Win/Host/WinHost.c   | 6 +++---
>> EmulatorPkg/EmulatorPkg.dsc      | 7 ++++++-
>> EmulatorPkg/Win/Host/WinHost.inf | 6 ++++++
>> 3 files changed, 15 insertions(+), 4 deletions(-)
>> 
>> diff --git a/EmulatorPkg/Win/Host/WinHost.c
>> b/EmulatorPkg/Win/Host/WinHost.c index 9aba3c8959..e40ce32548 100644
>> --- a/EmulatorPkg/Win/Host/WinHost.c
>> +++ b/EmulatorPkg/Win/Host/WinHost.c
>> @@ -356,7 +356,7 @@ Returns:
>> INTN
>> EFIAPI
>> main (
>> -  IN  INTN  Argc,
>> +  IN  INT  Argc,
>>  IN  CHAR8 **Argv,
>>  IN  CHAR8 **Envp
>>  )
>> @@ -391,8 +391,8 @@ Returns:
>>  VOID                  *SecFile;
>>  CHAR16                *MemorySizeStr;
>>  CHAR16                *FirmwareVolumesStr;
>> -  UINT32                ProcessAffinityMask;
>> -  UINT32                SystemAffinityMask;
>> +  UINTN                 ProcessAffinityMask;
>> +  UINTN                 SystemAffinityMask;
>>  INT32                 LowBit;
>> 
>>  //
>> diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
>> index 20f1187713..72532f5daf 100644
>> --- a/EmulatorPkg/EmulatorPkg.dsc
>> +++ b/EmulatorPkg/EmulatorPkg.dsc
>> @@ -237,9 +237,10 @@
>> 
>> [Components]
>> !if "IA32" in $(ARCH) || "X64" in $(ARCH)
>> -  !if "MSFT" in $(FAMILY)
>> +  !if "MSFT" in $(FAMILY) || $(WIN_SEC_BUILD) == TRUE
>>    ##
>>    #  Emulator, OS WIN application
>> +    #  CLANG9 is cross OS tool chain. It depends on WIN_SEC_BUILD macro.
>>    ##
>>    EmulatorPkg/Win/Host/WinHost.inf
>>  !else
>> @@ -419,7 +420,11 @@
>> 
>>  MSFT:DEBUG_*_*_CC_FLAGS = /Od /Oy-
>>  MSFT:NOOPT_*_*_CC_FLAGS = /Od /Oy-
>> +  GCC:DEBUG_CLANG9_*_CC_FLAGS =-O0 -Wno-unused-command-line-
>> argument
>> + -Wno-incompatible-pointer-types -Wno-enum-conversion
>> + -Wno-incompatible-pointer-types -Wno-sometimes-uninitialized
>> + -Wno-constant-conversion -Wno-main-return-type
>> 
>>  MSFT:*_*_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
>> /SUBSYSTEM:CONSOLE
>>  MSFT:DEBUG_*_*_DLINK_FLAGS =
>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>>  MSFT:NOOPT_*_*_DLINK_FLAGS =
>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>> +  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
>> /SUBSYSTEM:CONSOLE
>> +  GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
>> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>> + GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
>> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>> diff --git a/EmulatorPkg/Win/Host/WinHost.inf
>> b/EmulatorPkg/Win/Host/WinHost.inf
>> index 631d5a6470..1adca10d79 100644
>> --- a/EmulatorPkg/Win/Host/WinHost.inf
>> +++ b/EmulatorPkg/Win/Host/WinHost.inf
>> @@ -95,3 +95,9 @@
>>  MSFT:*_VS2017_X64_DLINK_FLAGS      =
>> /LIBPATH:"%VCToolsInstallDir%lib\x64"
>> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
>> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
>> /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP
>> /OPT:REF /DEBUG /MACHINE:AMD64 /LTCG Kernel32.lib MSVCRTD.lib
>> vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib Winmm.lib Advapi32.lib
>>  MSFT:*_*_X64_ASM_FLAGS            == /nologo /W3 /WX /c /Cx /Zd /W0 /Zi
>>  MSFT:*_*_X64_ASMLINK_FLAGS        == /link /nologo
>> +
>> +  GCC:*_CLANG9_X64_DLINK_FLAGS ==
>> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
>> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
>> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
>> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
>> /LIBPATH:"%VCToolsInstallDir%lib\x64"   /NOLOGO /SUBSYSTEM:CONSOLE
>> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:AMD64
>> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
>> Winmm.lib Advapi32.lib /lldmap
>> /EXPORT:InitializeDriver=_ModuleEntryPoint
>> +  GCC:*_CLANG9_X64_CC_FLAGS == -m64 -g -fshort-wchar
>> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
>> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D UNICODE
>> -D
>> + _CRT_SECURE_NO_DEPRECATE
>> +
>> +  GCC:*_CLANG9_IA32_DLINK_FLAGS ==
>> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
>> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
>> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86"
>> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86"
>> /LIBPATH:"%VCToolsInstallDir%ib\x86"   /NOLOGO /SUBSYSTEM:CONSOLE
>> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:I386
>> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
>> Winmm.lib Advapi32.lib /lldmap
>> /EXPORT:InitializeDriver=_ModuleEntryPoint
>> +  GCC:*_CLANG9_IA32_CC_FLAGS == -m32 -g -fshort-wchar
>> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
>> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D UNICODE
>> -D
>> + _CRT_SECURE_NO_DEPRECATE
>> --
>> 2.13.0.windows.1
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> 

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

[Leif Lindholm]

Hi Andrew,

Yeah, I'm pretty easy with regards to what we change it to.
Although if we're bikeshedding, I would prefer not using _ in the
toolchain profile name.

I'm ... optimistic ... it won't break any of my existing scripts, but
since the build system uses it as a
<toolchain profile>_<architecture>_<build target> separator, it would
be nice if we didn't risk confusion there.

(I would be totally happy with PECLANG, CLANGPE, PDBCLANG, CLANGPDB or
something along those lines.)

Regards,

Leif

On Thu, Nov 07, 2019 at 11:54:04AM -0600, Andrew Fish wrote:
> Leif,
> 
> I think I proposed CLANG_PDB or CLANG_PECOFF. I seem to like CLANG_PDB as assuming the PDE debugging experience is awesome/exists on Linux and macOS is not a given. 
> 
> Thanks,
> 
> Andrew Fish
> 
> > On Nov 7, 2019, at 11:19 AM, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> > 
> > Oops, sorry, missed this in search.
> > 
> > On Wed, Oct 30, 2019 at 03:43:44PM +0000, Liming Gao wrote:
> >> Andrew:
> >> 
> >>  I prefer to keep short CLANG9 as the tool chain name. I add wiki
> >>  page
> >>  https://github.com/tianocore/tianocore.github.io/wiki/CLANG9-Tools-Chain
> >>  to introduce it.
> > 
> > Why should users be expected to go and read documentation in order to
> > learn that fundamental and incompatible changes to output and debug
> > format has been made as part of what looks like a simple version bump?
> > 
> >>  And, we have CLANG38 tool chain. It generates ELF
> >>  image and DWARF debug symbol format. It can work with LLVM 9.0
> >>  release. Current tool chain tag name includes compiler name and
> >>  version. There is no specific info in the tool chain name. The
> >>  developer can get the more tool chain information from wiki page.
> > 
> > We aleady have the problem that people think they need to use GCC5 to
> > build EDK2 since that is the highest named GCC toolchain profile.
> > 
> > Let's not make this situation *worse* by setting up a multidimensional
> > feature matrix, based off random numerical values.
> > 
> > So say that we next have a pressing need to create a new toolchain
> > profile for clang 10, using the old ELF mechanism. Are you then
> > suggesting we set up a table on said wiki page where people have to go
> > and look up what the object and debug formats are for each CLANG##
> > toolchain profile?
> > 
> > And what if you then end up needing to do the same for the PDB
> > flavour?
> > 
> >>  CLANG9 is designed to support Emulator for Windows host only.
> > 
> > Which is why it makes no sense to name it as a successor of
> > CLANG38.
> > 
> >>  CLANG38 may be used for Emulator in Linux or Mac. I don’t
> >>  try it before.
> >> 
> >>  CLANG9 goal is to align the same compiler in the different host
> >>  development environment. It can replace VS or GCC compiler. On
> >>  Windows Host, I verify VS debugger for the source level debug. On
> >>  Linux host, I have not verified llvm debugger. I will investigate
> >>  the debugger solution for OVMF in Linux host.
> > 
> > We are not asking you to throw out this toolchain profile.
> > 
> > We are saying that since the functionality it provides is completely
> > unrelated to that of CLANG38, it should not be named in a way that
> > suggests it is merely a revision update.
> > 
> > /
> >    Leif
> > 
> >> Thanks
> >> Liming
> >> From: afish@apple.com <afish@apple.com>
> >> Sent: Saturday, October 26, 2019 2:45 AM
> >> To: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>
> >> Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>
> >> Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
> >> 
> >> Liming,
> >> 
> >> Sorry I missed this mail. Thanks for the info! I was doing some research into this too and now I think I finally understand. I think the name for the tool chain really confused me and we should think about changing the name.
> >> 
> >> From what I understand CLANG9 means produce PE/COFF directly and used the PDB debugging format. I see from the llvm site that the linker can produce PDB directly as you mention. This all makes sense to me now as LLVM tries to make it easy to be a drop in replacement for VC++ or GCC. So this tool chain is designed to be able to cross build a "Windows App" on a Linux or macOS. It also looks like the llvm debugger, lldb, is lagging in its support for PDB based debugging.
> >> 
> >> 
> >> Anyway I think Leif and I agree the toolchain name is very confusing. I'd rather see it called CLANG9_WIN or CLANG_PDB.
> >> 
> >> 
> >> On Oct 18, 2019, at 7:27 AM, Liming Gao <liming.gao@intel.com<mailto:liming.gao@intel.com>> wrote:
> >> 
> >> Andrew:
> >> Here is the cover letter on CLANG9 introduction. https://edk2.groups.io/g/devel/message/49157
> >> 
> >> 1)      Yes. CLANG9 tool chain is added to directly generate PE/COFF image (EFI image).
> >> This tool chain uses LLVM clang C compiler and lld linker, generates PE/COFF
> >> image and PDB compatible debug symbol format. Now, it supports IA32/X64 Archs.
> >> LLVM clang C compiler and lld linker are the standalone tool set. They don’t depend other lib to generate PE/COFF image.
> >> 
> >> 2)      Yes. CLANG9 is the cross OS tool chain. It can work on Windows/Linux/Mac host OS.
> >> LLVM LLD linker uses Windows style arguments. I verify CLANG9 for Ovmf3264 in Windows/Linux host OS.
> >> 
> >> 
> >> On Linux can you source level debug Ovmf?
> >> 
> >> 
> >> 3)     This patch enables WinHost in Windows. It doesn’t enable UnixHost. Now, EmulatorPkg with CLANG9 only works on Windows Host.
> >> This patch can make other modules pass build in Windows/Linux/Mac only if LLVM9 tool set is installed.
> >> But, the generated image may not work on Linux/Mac. I agree below linker flags are specific to windows host.
> >> So, I suggest to add the conditional statement of $(WIN_HOST_BUILD) == TRUE for them.
> >> 
> >> 
> >> For the EmulatorPkg the Host is a native App for that OS you build on, but it seems like CLANG9 is targeted to build Windows Apps. I'm not sure  but you might be able to override all the linker commands to build a native app, or just use the system linker for the Host?
> >> 
> >> I'm not sure how well debugging will work mixing PDB and DWARF symbol formats?
> >> 
> >> Thanks,
> >> 
> >> Andrew Fish
> >> 
> >> 
> >> 
> >> !if $(WIN_HOST_BUILD) == TRUE
> >>  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096 /SUBSYSTEM:CONSOLE
> >>  GCC:DEBUG_CLANG9_*_DLINK_FLAGS = /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> >>  GCC:NOOPT_CLANG9_*_DLINK_FLAGS = /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> >> !endif
> >> 
> >> Thanks
> >> Liming
> >> From: afish@apple.com<mailto:afish@apple.com> <afish@apple.com<mailto:afish@apple.com>>
> >> Sent: Friday, October 18, 2019 1:15 AM
> >> To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> >> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Justen, Jordan L <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
> >> Subject: Re: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
> >> 
> >> Ray,
> >> 
> >> Sorry I'm coming a little late to this and I'm confused. I have some questions?
> >> 1) Does CLANG9 imply CLANGPE?
> >> 2) Does CLANGPE work on Linux and macOS? Can you pass the Windows style arguments to CLANGPE linker on Linux and macOS?
> >> 3) For the EmulatorPkg don't you have the extra requirement that compiler needs a standard C lib (or platform specific libs) to function?
> >>       a) GCC:*_CLANG9_*_DLINK_FLAGS in EmulatorPkg.dsc seems to imply the Linux and macOS systems will have a Windows SKD dir and a lot of Windows DLLs? Does all that come when you install CLANG9 when you install it on Linux or macOS?
> >> 
> >> 
> >> 
> >> So I guess I'm asking is the linker really the same for CLANG9 on all systems? I guess the answer could be yes, but it seems the C lib for the Host App is still an App for that OS and is OS dependent?
> >> 
> >> 
> >> 
> >> Sorry if I'm missing something fundamental and this is a dumb question.
> >> 
> >> 
> >> 
> >> Thanks,
> >> 
> >> 
> >> 
> >> Andrew Fish
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> On Oct 17, 2019, at 12:27 AM, Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>> wrote:
> >> 
> >> Liming,
> >> Emulator is using a generic SEC module. The host specific module is called "Host".
> >> So I prefer to change the macro to "WIN_HOST_BUILD", with this change, Reviewed-by: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> >> 
> >> 
> >> 
> >> -----Original Message-----
> >> From: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> >> Sent: Thursday, October 17, 2019 2:56 PM
> >> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> >> Cc: Justen, Jordan L <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>; Andrew Fish
> >> <afish@apple.com<mailto:afish@apple.com>>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> >> Subject: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
> >> 
> >> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
> >> 1. Add WIN_SEC_BUILD macro check for CLANG9 tool chain build -p
> >> EmulatorPkg\EmulatorPkg.dsc -a IA32 -DWIN_SEC_BUILD=TRUE -t CLANG9
> >> build -p EmulatorPkg\EmulatorPkg.dsc -a X64 -DWIN_SEC_BUILD=TRUE -t
> >> CLANG9 2. Append CLANG CC and LINK flags to generate windows HOST.
> >> 3. Fix WinHost issue to call GetProcessAffinityMask() API.
> >>  The input parameter should be UINTN pointer instead of UINT32 pointer.
> >> 
> >> Cc: Jordan Justen <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
> >> Cc: Andrew Fish <afish@apple.com<mailto:afish@apple.com>>
> >> Cc: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> >> Signed-off-by: Liming Gao <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> >> ---
> >> EmulatorPkg/Win/Host/WinHost.c   | 6 +++---
> >> EmulatorPkg/EmulatorPkg.dsc      | 7 ++++++-
> >> EmulatorPkg/Win/Host/WinHost.inf | 6 ++++++
> >> 3 files changed, 15 insertions(+), 4 deletions(-)
> >> 
> >> diff --git a/EmulatorPkg/Win/Host/WinHost.c
> >> b/EmulatorPkg/Win/Host/WinHost.c index 9aba3c8959..e40ce32548 100644
> >> --- a/EmulatorPkg/Win/Host/WinHost.c
> >> +++ b/EmulatorPkg/Win/Host/WinHost.c
> >> @@ -356,7 +356,7 @@ Returns:
> >> INTN
> >> EFIAPI
> >> main (
> >> -  IN  INTN  Argc,
> >> +  IN  INT  Argc,
> >>  IN  CHAR8 **Argv,
> >>  IN  CHAR8 **Envp
> >>  )
> >> @@ -391,8 +391,8 @@ Returns:
> >>  VOID                  *SecFile;
> >>  CHAR16                *MemorySizeStr;
> >>  CHAR16                *FirmwareVolumesStr;
> >> -  UINT32                ProcessAffinityMask;
> >> -  UINT32                SystemAffinityMask;
> >> +  UINTN                 ProcessAffinityMask;
> >> +  UINTN                 SystemAffinityMask;
> >>  INT32                 LowBit;
> >> 
> >>  //
> >> diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
> >> index 20f1187713..72532f5daf 100644
> >> --- a/EmulatorPkg/EmulatorPkg.dsc
> >> +++ b/EmulatorPkg/EmulatorPkg.dsc
> >> @@ -237,9 +237,10 @@
> >> 
> >> [Components]
> >> !if "IA32" in $(ARCH) || "X64" in $(ARCH)
> >> -  !if "MSFT" in $(FAMILY)
> >> +  !if "MSFT" in $(FAMILY) || $(WIN_SEC_BUILD) == TRUE
> >>    ##
> >>    #  Emulator, OS WIN application
> >> +    #  CLANG9 is cross OS tool chain. It depends on WIN_SEC_BUILD macro.
> >>    ##
> >>    EmulatorPkg/Win/Host/WinHost.inf
> >>  !else
> >> @@ -419,7 +420,11 @@
> >> 
> >>  MSFT:DEBUG_*_*_CC_FLAGS = /Od /Oy-
> >>  MSFT:NOOPT_*_*_CC_FLAGS = /Od /Oy-
> >> +  GCC:DEBUG_CLANG9_*_CC_FLAGS =-O0 -Wno-unused-command-line-
> >> argument
> >> + -Wno-incompatible-pointer-types -Wno-enum-conversion
> >> + -Wno-incompatible-pointer-types -Wno-sometimes-uninitialized
> >> + -Wno-constant-conversion -Wno-main-return-type
> >> 
> >>  MSFT:*_*_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
> >> /SUBSYSTEM:CONSOLE
> >>  MSFT:DEBUG_*_*_DLINK_FLAGS =
> >> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> >>  MSFT:NOOPT_*_*_DLINK_FLAGS =
> >> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> >> +  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
> >> /SUBSYSTEM:CONSOLE
> >> +  GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
> >> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> >> + GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
> >> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> >> diff --git a/EmulatorPkg/Win/Host/WinHost.inf
> >> b/EmulatorPkg/Win/Host/WinHost.inf
> >> index 631d5a6470..1adca10d79 100644
> >> --- a/EmulatorPkg/Win/Host/WinHost.inf
> >> +++ b/EmulatorPkg/Win/Host/WinHost.inf
> >> @@ -95,3 +95,9 @@
> >>  MSFT:*_VS2017_X64_DLINK_FLAGS      =
> >> /LIBPATH:"%VCToolsInstallDir%lib\x64"
> >> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
> >> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
> >> /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP
> >> /OPT:REF /DEBUG /MACHINE:AMD64 /LTCG Kernel32.lib MSVCRTD.lib
> >> vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib Winmm.lib Advapi32.lib
> >>  MSFT:*_*_X64_ASM_FLAGS            == /nologo /W3 /WX /c /Cx /Zd /W0 /Zi
> >>  MSFT:*_*_X64_ASMLINK_FLAGS        == /link /nologo
> >> +
> >> +  GCC:*_CLANG9_X64_DLINK_FLAGS ==
> >> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
> >> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> >> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
> >> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
> >> /LIBPATH:"%VCToolsInstallDir%lib\x64"   /NOLOGO /SUBSYSTEM:CONSOLE
> >> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:AMD64
> >> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
> >> Winmm.lib Advapi32.lib /lldmap
> >> /EXPORT:InitializeDriver=_ModuleEntryPoint
> >> +  GCC:*_CLANG9_X64_CC_FLAGS == -m64 -g -fshort-wchar
> >> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
> >> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D UNICODE
> >> -D
> >> + _CRT_SECURE_NO_DEPRECATE
> >> +
> >> +  GCC:*_CLANG9_IA32_DLINK_FLAGS ==
> >> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
> >> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> >> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86"
> >> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86"
> >> /LIBPATH:"%VCToolsInstallDir%ib\x86"   /NOLOGO /SUBSYSTEM:CONSOLE
> >> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:I386
> >> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
> >> Winmm.lib Advapi32.lib /lldmap
> >> /EXPORT:InitializeDriver=_ModuleEntryPoint
> >> +  GCC:*_CLANG9_IA32_CC_FLAGS == -m32 -g -fshort-wchar
> >> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
> >> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D UNICODE
> >> -D
> >> + _CRT_SECURE_NO_DEPRECATE
> >> --
> >> 2.13.0.windows.1
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> > 
> > 
> > 
> 

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

[Andrew Fish]

> On Nov 7, 2019, at 12:37 PM, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> 
> Hi Andrew,
> 
> Yeah, I'm pretty easy with regards to what we change it to.
> Although if we're bikeshedding, I would prefer not using _ in the
> toolchain profile name.
> 
> I'm ... optimistic ... it won't break any of my existing scripts, but
> since the build system uses it as a
> <toolchain profile>_<architecture>_<build target> separator, it would
> be nice if we didn't risk confusion there.
> 
> (I would be totally happy with PECLANG, CLANGPE, PDBCLANG, CLANGPDB or
> something along those lines.)
> 

Leif,

Sorry the _ is muscle  memory. I like adding the PDB part as the clang debugger does not support PDB for 1st class debugging. 

Thanks,

Andrew Fish

> Regards,
> 
> Leif
> 
> On Thu, Nov 07, 2019 at 11:54:04AM -0600, Andrew Fish wrote:
>> Leif,
>> 
>> I think I proposed CLANG_PDB or CLANG_PECOFF. I seem to like CLANG_PDB as assuming the PDE debugging experience is awesome/exists on Linux and macOS is not a given. 
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>>> On Nov 7, 2019, at 11:19 AM, Leif Lindholm <leif.lindholm@linaro.org> wrote:
>>> 
>>> Oops, sorry, missed this in search.
>>> 
>>> On Wed, Oct 30, 2019 at 03:43:44PM +0000, Liming Gao wrote:
>>>> Andrew:
>>>> 
>>>> I prefer to keep short CLANG9 as the tool chain name. I add wiki
>>>> page
>>>> https://github.com/tianocore/tianocore.github.io/wiki/CLANG9-Tools-Chain
>>>> to introduce it.
>>> 
>>> Why should users be expected to go and read documentation in order to
>>> learn that fundamental and incompatible changes to output and debug
>>> format has been made as part of what looks like a simple version bump?
>>> 
>>>> And, we have CLANG38 tool chain. It generates ELF
>>>> image and DWARF debug symbol format. It can work with LLVM 9.0
>>>> release. Current tool chain tag name includes compiler name and
>>>> version. There is no specific info in the tool chain name. The
>>>> developer can get the more tool chain information from wiki page.
>>> 
>>> We aleady have the problem that people think they need to use GCC5 to
>>> build EDK2 since that is the highest named GCC toolchain profile.
>>> 
>>> Let's not make this situation *worse* by setting up a multidimensional
>>> feature matrix, based off random numerical values.
>>> 
>>> So say that we next have a pressing need to create a new toolchain
>>> profile for clang 10, using the old ELF mechanism. Are you then
>>> suggesting we set up a table on said wiki page where people have to go
>>> and look up what the object and debug formats are for each CLANG##
>>> toolchain profile?
>>> 
>>> And what if you then end up needing to do the same for the PDB
>>> flavour?
>>> 
>>>> CLANG9 is designed to support Emulator for Windows host only.
>>> 
>>> Which is why it makes no sense to name it as a successor of
>>> CLANG38.
>>> 
>>>> CLANG38 may be used for Emulator in Linux or Mac. I don’t
>>>> try it before.
>>>> 
>>>> CLANG9 goal is to align the same compiler in the different host
>>>> development environment. It can replace VS or GCC compiler. On
>>>> Windows Host, I verify VS debugger for the source level debug. On
>>>> Linux host, I have not verified llvm debugger. I will investigate
>>>> the debugger solution for OVMF in Linux host.
>>> 
>>> We are not asking you to throw out this toolchain profile.
>>> 
>>> We are saying that since the functionality it provides is completely
>>> unrelated to that of CLANG38, it should not be named in a way that
>>> suggests it is merely a revision update.
>>> 
>>> /
>>>   Leif
>>> 
>>>> Thanks
>>>> Liming
>>>> From: afish@apple.com <afish@apple.com>
>>>> Sent: Saturday, October 26, 2019 2:45 AM
>>>> To: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>
>>>> Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>
>>>> Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
>>>> 
>>>> Liming,
>>>> 
>>>> Sorry I missed this mail. Thanks for the info! I was doing some research into this too and now I think I finally understand. I think the name for the tool chain really confused me and we should think about changing the name.
>>>> 
>>>> From what I understand CLANG9 means produce PE/COFF directly and used the PDB debugging format. I see from the llvm site that the linker can produce PDB directly as you mention. This all makes sense to me now as LLVM tries to make it easy to be a drop in replacement for VC++ or GCC. So this tool chain is designed to be able to cross build a "Windows App" on a Linux or macOS. It also looks like the llvm debugger, lldb, is lagging in its support for PDB based debugging.
>>>> 
>>>> 
>>>> Anyway I think Leif and I agree the toolchain name is very confusing. I'd rather see it called CLANG9_WIN or CLANG_PDB.
>>>> 
>>>> 
>>>> On Oct 18, 2019, at 7:27 AM, Liming Gao <liming.gao@intel.com<mailto:liming.gao@intel.com>> wrote:
>>>> 
>>>> Andrew:
>>>> Here is the cover letter on CLANG9 introduction. https://edk2.groups.io/g/devel/message/49157
>>>> 
>>>> 1)      Yes. CLANG9 tool chain is added to directly generate PE/COFF image (EFI image).
>>>> This tool chain uses LLVM clang C compiler and lld linker, generates PE/COFF
>>>> image and PDB compatible debug symbol format. Now, it supports IA32/X64 Archs.
>>>> LLVM clang C compiler and lld linker are the standalone tool set. They don’t depend other lib to generate PE/COFF image.
>>>> 
>>>> 2)      Yes. CLANG9 is the cross OS tool chain. It can work on Windows/Linux/Mac host OS.
>>>> LLVM LLD linker uses Windows style arguments. I verify CLANG9 for Ovmf3264 in Windows/Linux host OS.
>>>> 
>>>> 
>>>> On Linux can you source level debug Ovmf?
>>>> 
>>>> 
>>>> 3)     This patch enables WinHost in Windows. It doesn’t enable UnixHost. Now, EmulatorPkg with CLANG9 only works on Windows Host.
>>>> This patch can make other modules pass build in Windows/Linux/Mac only if LLVM9 tool set is installed.
>>>> But, the generated image may not work on Linux/Mac. I agree below linker flags are specific to windows host.
>>>> So, I suggest to add the conditional statement of $(WIN_HOST_BUILD) == TRUE for them.
>>>> 
>>>> 
>>>> For the EmulatorPkg the Host is a native App for that OS you build on, but it seems like CLANG9 is targeted to build Windows Apps. I'm not sure  but you might be able to override all the linker commands to build a native app, or just use the system linker for the Host?
>>>> 
>>>> I'm not sure how well debugging will work mixing PDB and DWARF symbol formats?
>>>> 
>>>> Thanks,
>>>> 
>>>> Andrew Fish
>>>> 
>>>> 
>>>> 
>>>> !if $(WIN_HOST_BUILD) == TRUE
>>>> GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096 /SUBSYSTEM:CONSOLE
>>>> GCC:DEBUG_CLANG9_*_DLINK_FLAGS = /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>>>> GCC:NOOPT_CLANG9_*_DLINK_FLAGS = /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>>>> !endif
>>>> 
>>>> Thanks
>>>> Liming
>>>> From: afish@apple.com<mailto:afish@apple.com> <afish@apple.com<mailto:afish@apple.com>>
>>>> Sent: Friday, October 18, 2019 1:15 AM
>>>> To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
>>>> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Justen, Jordan L <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
>>>> Subject: Re: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
>>>> 
>>>> Ray,
>>>> 
>>>> Sorry I'm coming a little late to this and I'm confused. I have some questions?
>>>> 1) Does CLANG9 imply CLANGPE?
>>>> 2) Does CLANGPE work on Linux and macOS? Can you pass the Windows style arguments to CLANGPE linker on Linux and macOS?
>>>> 3) For the EmulatorPkg don't you have the extra requirement that compiler needs a standard C lib (or platform specific libs) to function?
>>>>      a) GCC:*_CLANG9_*_DLINK_FLAGS in EmulatorPkg.dsc seems to imply the Linux and macOS systems will have a Windows SKD dir and a lot of Windows DLLs? Does all that come when you install CLANG9 when you install it on Linux or macOS?
>>>> 
>>>> 
>>>> 
>>>> So I guess I'm asking is the linker really the same for CLANG9 on all systems? I guess the answer could be yes, but it seems the C lib for the Host App is still an App for that OS and is OS dependent?
>>>> 
>>>> 
>>>> 
>>>> Sorry if I'm missing something fundamental and this is a dumb question.
>>>> 
>>>> 
>>>> 
>>>> Thanks,
>>>> 
>>>> 
>>>> 
>>>> Andrew Fish
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Oct 17, 2019, at 12:27 AM, Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>> wrote:
>>>> 
>>>> Liming,
>>>> Emulator is using a generic SEC module. The host specific module is called "Host".
>>>> So I prefer to change the macro to "WIN_HOST_BUILD", with this change, Reviewed-by: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
>>>> 
>>>> 
>>>> 
>>>> -----Original Message-----
>>>> From: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
>>>> Sent: Thursday, October 17, 2019 2:56 PM
>>>> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
>>>> Cc: Justen, Jordan L <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>; Andrew Fish
>>>> <afish@apple.com<mailto:afish@apple.com>>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
>>>> Subject: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
>>>> 
>>>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
>>>> 1. Add WIN_SEC_BUILD macro check for CLANG9 tool chain build -p
>>>> EmulatorPkg\EmulatorPkg.dsc -a IA32 -DWIN_SEC_BUILD=TRUE -t CLANG9
>>>> build -p EmulatorPkg\EmulatorPkg.dsc -a X64 -DWIN_SEC_BUILD=TRUE -t
>>>> CLANG9 2. Append CLANG CC and LINK flags to generate windows HOST.
>>>> 3. Fix WinHost issue to call GetProcessAffinityMask() API.
>>>> The input parameter should be UINTN pointer instead of UINT32 pointer.
>>>> 
>>>> Cc: Jordan Justen <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
>>>> Cc: Andrew Fish <afish@apple.com<mailto:afish@apple.com>>
>>>> Cc: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
>>>> Signed-off-by: Liming Gao <liming.gao@intel.com<mailto:liming.gao@intel.com>>
>>>> ---
>>>> EmulatorPkg/Win/Host/WinHost.c   | 6 +++---
>>>> EmulatorPkg/EmulatorPkg.dsc      | 7 ++++++-
>>>> EmulatorPkg/Win/Host/WinHost.inf | 6 ++++++
>>>> 3 files changed, 15 insertions(+), 4 deletions(-)
>>>> 
>>>> diff --git a/EmulatorPkg/Win/Host/WinHost.c
>>>> b/EmulatorPkg/Win/Host/WinHost.c index 9aba3c8959..e40ce32548 100644
>>>> --- a/EmulatorPkg/Win/Host/WinHost.c
>>>> +++ b/EmulatorPkg/Win/Host/WinHost.c
>>>> @@ -356,7 +356,7 @@ Returns:
>>>> INTN
>>>> EFIAPI
>>>> main (
>>>> -  IN  INTN  Argc,
>>>> +  IN  INT  Argc,
>>>> IN  CHAR8 **Argv,
>>>> IN  CHAR8 **Envp
>>>> )
>>>> @@ -391,8 +391,8 @@ Returns:
>>>> VOID                  *SecFile;
>>>> CHAR16                *MemorySizeStr;
>>>> CHAR16                *FirmwareVolumesStr;
>>>> -  UINT32                ProcessAffinityMask;
>>>> -  UINT32                SystemAffinityMask;
>>>> +  UINTN                 ProcessAffinityMask;
>>>> +  UINTN                 SystemAffinityMask;
>>>> INT32                 LowBit;
>>>> 
>>>> //
>>>> diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
>>>> index 20f1187713..72532f5daf 100644
>>>> --- a/EmulatorPkg/EmulatorPkg.dsc
>>>> +++ b/EmulatorPkg/EmulatorPkg.dsc
>>>> @@ -237,9 +237,10 @@
>>>> 
>>>> [Components]
>>>> !if "IA32" in $(ARCH) || "X64" in $(ARCH)
>>>> -  !if "MSFT" in $(FAMILY)
>>>> +  !if "MSFT" in $(FAMILY) || $(WIN_SEC_BUILD) == TRUE
>>>>   ##
>>>>   #  Emulator, OS WIN application
>>>> +    #  CLANG9 is cross OS tool chain. It depends on WIN_SEC_BUILD macro.
>>>>   ##
>>>>   EmulatorPkg/Win/Host/WinHost.inf
>>>> !else
>>>> @@ -419,7 +420,11 @@
>>>> 
>>>> MSFT:DEBUG_*_*_CC_FLAGS = /Od /Oy-
>>>> MSFT:NOOPT_*_*_CC_FLAGS = /Od /Oy-
>>>> +  GCC:DEBUG_CLANG9_*_CC_FLAGS =-O0 -Wno-unused-command-line-
>>>> argument
>>>> + -Wno-incompatible-pointer-types -Wno-enum-conversion
>>>> + -Wno-incompatible-pointer-types -Wno-sometimes-uninitialized
>>>> + -Wno-constant-conversion -Wno-main-return-type
>>>> 
>>>> MSFT:*_*_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
>>>> /SUBSYSTEM:CONSOLE
>>>> MSFT:DEBUG_*_*_DLINK_FLAGS =
>>>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>>>> MSFT:NOOPT_*_*_DLINK_FLAGS =
>>>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>>>> +  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
>>>> /SUBSYSTEM:CONSOLE
>>>> +  GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
>>>> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>>>> + GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
>>>> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>>>> diff --git a/EmulatorPkg/Win/Host/WinHost.inf
>>>> b/EmulatorPkg/Win/Host/WinHost.inf
>>>> index 631d5a6470..1adca10d79 100644
>>>> --- a/EmulatorPkg/Win/Host/WinHost.inf
>>>> +++ b/EmulatorPkg/Win/Host/WinHost.inf
>>>> @@ -95,3 +95,9 @@
>>>> MSFT:*_VS2017_X64_DLINK_FLAGS      =
>>>> /LIBPATH:"%VCToolsInstallDir%lib\x64"
>>>> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
>>>> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
>>>> /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP
>>>> /OPT:REF /DEBUG /MACHINE:AMD64 /LTCG Kernel32.lib MSVCRTD.lib
>>>> vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib Winmm.lib Advapi32.lib
>>>> MSFT:*_*_X64_ASM_FLAGS            == /nologo /W3 /WX /c /Cx /Zd /W0 /Zi
>>>> MSFT:*_*_X64_ASMLINK_FLAGS        == /link /nologo
>>>> +
>>>> +  GCC:*_CLANG9_X64_DLINK_FLAGS ==
>>>> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
>>>> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
>>>> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
>>>> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
>>>> /LIBPATH:"%VCToolsInstallDir%lib\x64"   /NOLOGO /SUBSYSTEM:CONSOLE
>>>> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:AMD64
>>>> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
>>>> Winmm.lib Advapi32.lib /lldmap
>>>> /EXPORT:InitializeDriver=_ModuleEntryPoint
>>>> +  GCC:*_CLANG9_X64_CC_FLAGS == -m64 -g -fshort-wchar
>>>> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
>>>> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D UNICODE
>>>> -D
>>>> + _CRT_SECURE_NO_DEPRECATE
>>>> +
>>>> +  GCC:*_CLANG9_IA32_DLINK_FLAGS ==
>>>> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
>>>> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
>>>> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86"
>>>> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86"
>>>> /LIBPATH:"%VCToolsInstallDir%ib\x86"   /NOLOGO /SUBSYSTEM:CONSOLE
>>>> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:I386
>>>> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
>>>> Winmm.lib Advapi32.lib /lldmap
>>>> /EXPORT:InitializeDriver=_ModuleEntryPoint
>>>> +  GCC:*_CLANG9_IA32_CC_FLAGS == -m32 -g -fshort-wchar
>>>> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
>>>> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D UNICODE
>>>> -D
>>>> + _CRT_SECURE_NO_DEPRECATE
>>>> --
>>>> 2.13.0.windows.1
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

[Liming Gao]

Andrew and Leif:
  Thanks for your comment. CLANG9 is different from CLANG38. And, CLANG9 will support LLVM9 or the above. 
  So, this tool chain should have the specific word for its purpose, and remove the version 9 to avoid the confuse. 

  I prefer the tool chain name as CLANGPE or CLANGPDB. CLANGPE may be better. Now, CLANG9 tool chain 
  build rule family just uses CLANGPE. CLANGPE lets user know this tool chain generates PE/COFF image. 
  And, PE/COFF image debug symbol is PDB. So, PE also means PDB. 

  Last, I just review the changes. Tool chain name update is not big. If you accept CLANGPE as tool chain name, 
  I will send the patch soon to catch 201911 stable tag. 

Thanks
Liming
>-----Original Message-----
>From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Leif
>Lindholm
>Sent: Friday, November 08, 2019 2:37 AM
>To: Andrew Fish <afish@apple.com>
>Cc: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>; Ni, Ray
><ray.ni@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>
>Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool
>chain
>
>Hi Andrew,
>
>Yeah, I'm pretty easy with regards to what we change it to.
>Although if we're bikeshedding, I would prefer not using _ in the
>toolchain profile name.
>
>I'm ... optimistic ... it won't break any of my existing scripts, but
>since the build system uses it as a
><toolchain profile>_<architecture>_<build target> separator, it would
>be nice if we didn't risk confusion there.
>
>(I would be totally happy with PECLANG, CLANGPE, PDBCLANG, CLANGPDB or
>something along those lines.)
>
>Regards,
>
>Leif
>
>On Thu, Nov 07, 2019 at 11:54:04AM -0600, Andrew Fish wrote:
>> Leif,
>>
>> I think I proposed CLANG_PDB or CLANG_PECOFF. I seem to like
>CLANG_PDB as assuming the PDE debugging experience is awesome/exists
>on Linux and macOS is not a given.
>>
>> Thanks,
>>
>> Andrew Fish
>>
>> > On Nov 7, 2019, at 11:19 AM, Leif Lindholm <leif.lindholm@linaro.org>
>wrote:
>> >
>> > Oops, sorry, missed this in search.
>> >
>> > On Wed, Oct 30, 2019 at 03:43:44PM +0000, Liming Gao wrote:
>> >> Andrew:
>> >>
>> >>  I prefer to keep short CLANG9 as the tool chain name. I add wiki
>> >>  page
>> >>  https://github.com/tianocore/tianocore.github.io/wiki/CLANG9-Tools-
>Chain
>> >>  to introduce it.
>> >
>> > Why should users be expected to go and read documentation in order to
>> > learn that fundamental and incompatible changes to output and debug
>> > format has been made as part of what looks like a simple version bump?
>> >
>> >>  And, we have CLANG38 tool chain. It generates ELF
>> >>  image and DWARF debug symbol format. It can work with LLVM 9.0
>> >>  release. Current tool chain tag name includes compiler name and
>> >>  version. There is no specific info in the tool chain name. The
>> >>  developer can get the more tool chain information from wiki page.
>> >
>> > We aleady have the problem that people think they need to use GCC5 to
>> > build EDK2 since that is the highest named GCC toolchain profile.
>> >
>> > Let's not make this situation *worse* by setting up a multidimensional
>> > feature matrix, based off random numerical values.
>> >
>> > So say that we next have a pressing need to create a new toolchain
>> > profile for clang 10, using the old ELF mechanism. Are you then
>> > suggesting we set up a table on said wiki page where people have to go
>> > and look up what the object and debug formats are for each CLANG##
>> > toolchain profile?
>> >
>> > And what if you then end up needing to do the same for the PDB
>> > flavour?
>> >
>> >>  CLANG9 is designed to support Emulator for Windows host only.
>> >
>> > Which is why it makes no sense to name it as a successor of
>> > CLANG38.
>> >
>> >>  CLANG38 may be used for Emulator in Linux or Mac. I don’t
>> >>  try it before.
>> >>
>> >>  CLANG9 goal is to align the same compiler in the different host
>> >>  development environment. It can replace VS or GCC compiler. On
>> >>  Windows Host, I verify VS debugger for the source level debug. On
>> >>  Linux host, I have not verified llvm debugger. I will investigate
>> >>  the debugger solution for OVMF in Linux host.
>> >
>> > We are not asking you to throw out this toolchain profile.
>> >
>> > We are saying that since the functionality it provides is completely
>> > unrelated to that of CLANG38, it should not be named in a way that
>> > suggests it is merely a revision update.
>> >
>> > /
>> >    Leif
>> >
>> >> Thanks
>> >> Liming
>> >> From: afish@apple.com <afish@apple.com>
>> >> Sent: Saturday, October 26, 2019 2:45 AM
>> >> To: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>
>> >> Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L
><jordan.l.justen@intel.com>
>> >> Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9
>tool chain
>> >>
>> >> Liming,
>> >>
>> >> Sorry I missed this mail. Thanks for the info! I was doing some research
>into this too and now I think I finally understand. I think the name for the tool
>chain really confused me and we should think about changing the name.
>> >>
>> >> From what I understand CLANG9 means produce PE/COFF directly and
>used the PDB debugging format. I see from the llvm site that the linker can
>produce PDB directly as you mention. This all makes sense to me now as LLVM
>tries to make it easy to be a drop in replacement for VC++ or GCC. So this tool
>chain is designed to be able to cross build a "Windows App" on a Linux or
>macOS. It also looks like the llvm debugger, lldb, is lagging in its support for
>PDB based debugging.
>> >>
>> >>
>> >> Anyway I think Leif and I agree the toolchain name is very confusing. I'd
>rather see it called CLANG9_WIN or CLANG_PDB.
>> >>
>> >>
>> >> On Oct 18, 2019, at 7:27 AM, Liming Gao
><liming.gao@intel.com<mailto:liming.gao@intel.com>> wrote:
>> >>
>> >> Andrew:
>> >> Here is the cover letter on CLANG9 introduction.
>https://edk2.groups.io/g/devel/message/49157
>> >>
>> >> 1)      Yes. CLANG9 tool chain is added to directly generate PE/COFF image
>(EFI image).
>> >> This tool chain uses LLVM clang C compiler and lld linker, generates
>PE/COFF
>> >> image and PDB compatible debug symbol format. Now, it supports
>IA32/X64 Archs.
>> >> LLVM clang C compiler and lld linker are the standalone tool set. They
>don’t depend other lib to generate PE/COFF image.
>> >>
>> >> 2)      Yes. CLANG9 is the cross OS tool chain. It can work on
>Windows/Linux/Mac host OS.
>> >> LLVM LLD linker uses Windows style arguments. I verify CLANG9 for
>Ovmf3264 in Windows/Linux host OS.
>> >>
>> >>
>> >> On Linux can you source level debug Ovmf?
>> >>
>> >>
>> >> 3)     This patch enables WinHost in Windows. It doesn’t enable UnixHost.
>Now, EmulatorPkg with CLANG9 only works on Windows Host.
>> >> This patch can make other modules pass build in Windows/Linux/Mac
>only if LLVM9 tool set is installed.
>> >> But, the generated image may not work on Linux/Mac. I agree below
>linker flags are specific to windows host.
>> >> So, I suggest to add the conditional statement of $(WIN_HOST_BUILD)
>== TRUE for them.
>> >>
>> >>
>> >> For the EmulatorPkg the Host is a native App for that OS you build on, but
>it seems like CLANG9 is targeted to build Windows Apps. I'm not sure  but you
>might be able to override all the linker commands to build a native app, or just
>use the system linker for the Host?
>> >>
>> >> I'm not sure how well debugging will work mixing PDB and DWARF
>symbol formats?
>> >>
>> >> Thanks,
>> >>
>> >> Andrew Fish
>> >>
>> >>
>> >>
>> >> !if $(WIN_HOST_BUILD) == TRUE
>> >>  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
>/SUBSYSTEM:CONSOLE
>> >>  GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
>/EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>> >>  GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
>/EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>> >> !endif
>> >>
>> >> Thanks
>> >> Liming
>> >> From: afish@apple.com<mailto:afish@apple.com>
><afish@apple.com<mailto:afish@apple.com>>
>> >> Sent: Friday, October 18, 2019 1:15 AM
>> >> To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
>> >> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>;
>devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Justen, Jordan L
><jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
>> >> Subject: Re: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
>> >>
>> >> Ray,
>> >>
>> >> Sorry I'm coming a little late to this and I'm confused. I have some
>questions?
>> >> 1) Does CLANG9 imply CLANGPE?
>> >> 2) Does CLANGPE work on Linux and macOS? Can you pass the Windows
>style arguments to CLANGPE linker on Linux and macOS?
>> >> 3) For the EmulatorPkg don't you have the extra requirement that
>compiler needs a standard C lib (or platform specific libs) to function?
>> >>       a) GCC:*_CLANG9_*_DLINK_FLAGS in EmulatorPkg.dsc seems to
>imply the Linux and macOS systems will have a Windows SKD dir and a lot of
>Windows DLLs? Does all that come when you install CLANG9 when you install
>it on Linux or macOS?
>> >>
>> >>
>> >>
>> >> So I guess I'm asking is the linker really the same for CLANG9 on all
>systems? I guess the answer could be yes, but it seems the C lib for the Host
>App is still an App for that OS and is OS dependent?
>> >>
>> >>
>> >>
>> >> Sorry if I'm missing something fundamental and this is a dumb question.
>> >>
>> >>
>> >>
>> >> Thanks,
>> >>
>> >>
>> >>
>> >> Andrew Fish
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Oct 17, 2019, at 12:27 AM, Ni, Ray
><ray.ni@intel.com<mailto:ray.ni@intel.com>> wrote:
>> >>
>> >> Liming,
>> >> Emulator is using a generic SEC module. The host specific module is called
>"Host".
>> >> So I prefer to change the macro to "WIN_HOST_BUILD", with this change,
>Reviewed-by: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
>> >>
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
>> >> Sent: Thursday, October 17, 2019 2:56 PM
>> >> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
>> >> Cc: Justen, Jordan L
><jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>; Andrew
>Fish
>> >> <afish@apple.com<mailto:afish@apple.com>>; Ni, Ray
><ray.ni@intel.com<mailto:ray.ni@intel.com>>
>> >> Subject: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
>> >>
>> >> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
>> >> 1. Add WIN_SEC_BUILD macro check for CLANG9 tool chain build -p
>> >> EmulatorPkg\EmulatorPkg.dsc -a IA32 -DWIN_SEC_BUILD=TRUE -t
>CLANG9
>> >> build -p EmulatorPkg\EmulatorPkg.dsc -a X64 -DWIN_SEC_BUILD=TRUE -t
>> >> CLANG9 2. Append CLANG CC and LINK flags to generate windows HOST.
>> >> 3. Fix WinHost issue to call GetProcessAffinityMask() API.
>> >>  The input parameter should be UINTN pointer instead of UINT32 pointer.
>> >>
>> >> Cc: Jordan Justen
><jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
>> >> Cc: Andrew Fish <afish@apple.com<mailto:afish@apple.com>>
>> >> Cc: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
>> >> Signed-off-by: Liming Gao
><liming.gao@intel.com<mailto:liming.gao@intel.com>>
>> >> ---
>> >> EmulatorPkg/Win/Host/WinHost.c   | 6 +++---
>> >> EmulatorPkg/EmulatorPkg.dsc      | 7 ++++++-
>> >> EmulatorPkg/Win/Host/WinHost.inf | 6 ++++++
>> >> 3 files changed, 15 insertions(+), 4 deletions(-)
>> >>
>> >> diff --git a/EmulatorPkg/Win/Host/WinHost.c
>> >> b/EmulatorPkg/Win/Host/WinHost.c index 9aba3c8959..e40ce32548
>100644
>> >> --- a/EmulatorPkg/Win/Host/WinHost.c
>> >> +++ b/EmulatorPkg/Win/Host/WinHost.c
>> >> @@ -356,7 +356,7 @@ Returns:
>> >> INTN
>> >> EFIAPI
>> >> main (
>> >> -  IN  INTN  Argc,
>> >> +  IN  INT  Argc,
>> >>  IN  CHAR8 **Argv,
>> >>  IN  CHAR8 **Envp
>> >>  )
>> >> @@ -391,8 +391,8 @@ Returns:
>> >>  VOID                  *SecFile;
>> >>  CHAR16                *MemorySizeStr;
>> >>  CHAR16                *FirmwareVolumesStr;
>> >> -  UINT32                ProcessAffinityMask;
>> >> -  UINT32                SystemAffinityMask;
>> >> +  UINTN                 ProcessAffinityMask;
>> >> +  UINTN                 SystemAffinityMask;
>> >>  INT32                 LowBit;
>> >>
>> >>  //
>> >> diff --git a/EmulatorPkg/EmulatorPkg.dsc
>b/EmulatorPkg/EmulatorPkg.dsc
>> >> index 20f1187713..72532f5daf 100644
>> >> --- a/EmulatorPkg/EmulatorPkg.dsc
>> >> +++ b/EmulatorPkg/EmulatorPkg.dsc
>> >> @@ -237,9 +237,10 @@
>> >>
>> >> [Components]
>> >> !if "IA32" in $(ARCH) || "X64" in $(ARCH)
>> >> -  !if "MSFT" in $(FAMILY)
>> >> +  !if "MSFT" in $(FAMILY) || $(WIN_SEC_BUILD) == TRUE
>> >>    ##
>> >>    #  Emulator, OS WIN application
>> >> +    #  CLANG9 is cross OS tool chain. It depends on WIN_SEC_BUILD
>macro.
>> >>    ##
>> >>    EmulatorPkg/Win/Host/WinHost.inf
>> >>  !else
>> >> @@ -419,7 +420,11 @@
>> >>
>> >>  MSFT:DEBUG_*_*_CC_FLAGS = /Od /Oy-
>> >>  MSFT:NOOPT_*_*_CC_FLAGS = /Od /Oy-
>> >> +  GCC:DEBUG_CLANG9_*_CC_FLAGS =-O0 -Wno-unused-command-
>line-
>> >> argument
>> >> + -Wno-incompatible-pointer-types -Wno-enum-conversion
>> >> + -Wno-incompatible-pointer-types -Wno-sometimes-uninitialized
>> >> + -Wno-constant-conversion -Wno-main-return-type
>> >>
>> >>  MSFT:*_*_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
>> >> /SUBSYSTEM:CONSOLE
>> >>  MSFT:DEBUG_*_*_DLINK_FLAGS =
>> >> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>> >>  MSFT:NOOPT_*_*_DLINK_FLAGS =
>> >> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>> >> +  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
>> >> /SUBSYSTEM:CONSOLE
>> >> +  GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
>> >> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>> >> + GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
>> >> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>> >> diff --git a/EmulatorPkg/Win/Host/WinHost.inf
>> >> b/EmulatorPkg/Win/Host/WinHost.inf
>> >> index 631d5a6470..1adca10d79 100644
>> >> --- a/EmulatorPkg/Win/Host/WinHost.inf
>> >> +++ b/EmulatorPkg/Win/Host/WinHost.inf
>> >> @@ -95,3 +95,9 @@
>> >>  MSFT:*_VS2017_X64_DLINK_FLAGS      =
>> >> /LIBPATH:"%VCToolsInstallDir%lib\x64"
>> >> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
>> >> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
>> >> /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP
>> >> /OPT:REF /DEBUG /MACHINE:AMD64 /LTCG Kernel32.lib MSVCRTD.lib
>> >> vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib Winmm.lib Advapi32.lib
>> >>  MSFT:*_*_X64_ASM_FLAGS            == /nologo /W3 /WX /c /Cx /Zd /W0
>/Zi
>> >>  MSFT:*_*_X64_ASMLINK_FLAGS        == /link /nologo
>> >> +
>> >> +  GCC:*_CLANG9_X64_DLINK_FLAGS ==
>> >> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
>> >> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
>> >> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
>> >> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
>> >> /LIBPATH:"%VCToolsInstallDir%lib\x64"   /NOLOGO
>/SUBSYSTEM:CONSOLE
>> >> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:AMD64
>> >> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
>> >> Winmm.lib Advapi32.lib /lldmap
>> >> /EXPORT:InitializeDriver=_ModuleEntryPoint
>> >> +  GCC:*_CLANG9_X64_CC_FLAGS == -m64 -g -fshort-wchar
>> >> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
>> >> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D
>UNICODE
>> >> -D
>> >> + _CRT_SECURE_NO_DEPRECATE
>> >> +
>> >> +  GCC:*_CLANG9_IA32_DLINK_FLAGS ==
>> >> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
>> >> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
>> >> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86"
>> >> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86"
>> >> /LIBPATH:"%VCToolsInstallDir%ib\x86"   /NOLOGO
>/SUBSYSTEM:CONSOLE
>> >> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:I386
>> >> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
>> >> Winmm.lib Advapi32.lib /lldmap
>> >> /EXPORT:InitializeDriver=_ModuleEntryPoint
>> >> +  GCC:*_CLANG9_IA32_CC_FLAGS == -m32 -g -fshort-wchar
>> >> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
>> >> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D
>UNICODE
>> >> -D
>> >> + _CRT_SECURE_NO_DEPRECATE
>> >> --
>> >> 2.13.0.windows.1
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> >
>>
>
>

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

[Ni, Ray]

Liming,
PE is UEFI spec required executable binary format. I like CLANGPDB more than CLANGPE given LLVM may generate DRAWF debug symbol even when generating PE.

> -----Original Message-----
> From: Gao, Liming <liming.gao@intel.com>
> Sent: Friday, November 8, 2019 9:50 AM
> To: devel@edk2.groups.io; leif.lindholm@linaro.org; Andrew Fish <afish@apple.com>
> Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>; Gao, Liming <liming.gao@intel.com>; Shi,
> Steven <steven.shi@intel.com>
> Subject: RE: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
> 
> Andrew and Leif:
>   Thanks for your comment. CLANG9 is different from CLANG38. And, CLANG9 will support LLVM9 or the above.
>   So, this tool chain should have the specific word for its purpose, and remove the version 9 to avoid the confuse.
> 
>   I prefer the tool chain name as CLANGPE or CLANGPDB. CLANGPE may be better. Now, CLANG9 tool chain
>   build rule family just uses CLANGPE. CLANGPE lets user know this tool chain generates PE/COFF image.
>   And, PE/COFF image debug symbol is PDB. So, PE also means PDB.
> 
>   Last, I just review the changes. Tool chain name update is not big. If you accept CLANGPE as tool chain name,
>   I will send the patch soon to catch 201911 stable tag.
> 
> Thanks
> Liming
> >-----Original Message-----
> >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Leif
> >Lindholm
> >Sent: Friday, November 08, 2019 2:37 AM
> >To: Andrew Fish <afish@apple.com>
> >Cc: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>; Ni, Ray
> ><ray.ni@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>
> >Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool
> >chain
> >
> >Hi Andrew,
> >
> >Yeah, I'm pretty easy with regards to what we change it to.
> >Although if we're bikeshedding, I would prefer not using _ in the
> >toolchain profile name.
> >
> >I'm ... optimistic ... it won't break any of my existing scripts, but
> >since the build system uses it as a
> ><toolchain profile>_<architecture>_<build target> separator, it would
> >be nice if we didn't risk confusion there.
> >
> >(I would be totally happy with PECLANG, CLANGPE, PDBCLANG, CLANGPDB or
> >something along those lines.)
> >
> >Regards,
> >
> >Leif
> >
> >On Thu, Nov 07, 2019 at 11:54:04AM -0600, Andrew Fish wrote:
> >> Leif,
> >>
> >> I think I proposed CLANG_PDB or CLANG_PECOFF. I seem to like
> >CLANG_PDB as assuming the PDE debugging experience is awesome/exists
> >on Linux and macOS is not a given.
> >>
> >> Thanks,
> >>
> >> Andrew Fish
> >>
> >> > On Nov 7, 2019, at 11:19 AM, Leif Lindholm <leif.lindholm@linaro.org>
> >wrote:
> >> >
> >> > Oops, sorry, missed this in search.
> >> >
> >> > On Wed, Oct 30, 2019 at 03:43:44PM +0000, Liming Gao wrote:
> >> >> Andrew:
> >> >>
> >> >>  I prefer to keep short CLANG9 as the tool chain name. I add wiki
> >> >>  page
> >> >>  https://github.com/tianocore/tianocore.github.io/wiki/CLANG9-Tools-
> >Chain
> >> >>  to introduce it.
> >> >
> >> > Why should users be expected to go and read documentation in order to
> >> > learn that fundamental and incompatible changes to output and debug
> >> > format has been made as part of what looks like a simple version bump?
> >> >
> >> >>  And, we have CLANG38 tool chain. It generates ELF
> >> >>  image and DWARF debug symbol format. It can work with LLVM 9.0
> >> >>  release. Current tool chain tag name includes compiler name and
> >> >>  version. There is no specific info in the tool chain name. The
> >> >>  developer can get the more tool chain information from wiki page.
> >> >
> >> > We aleady have the problem that people think they need to use GCC5 to
> >> > build EDK2 since that is the highest named GCC toolchain profile.
> >> >
> >> > Let's not make this situation *worse* by setting up a multidimensional
> >> > feature matrix, based off random numerical values.
> >> >
> >> > So say that we next have a pressing need to create a new toolchain
> >> > profile for clang 10, using the old ELF mechanism. Are you then
> >> > suggesting we set up a table on said wiki page where people have to go
> >> > and look up what the object and debug formats are for each CLANG##
> >> > toolchain profile?
> >> >
> >> > And what if you then end up needing to do the same for the PDB
> >> > flavour?
> >> >
> >> >>  CLANG9 is designed to support Emulator for Windows host only.
> >> >
> >> > Which is why it makes no sense to name it as a successor of
> >> > CLANG38.
> >> >
> >> >>  CLANG38 may be used for Emulator in Linux or Mac. I don’t
> >> >>  try it before.
> >> >>
> >> >>  CLANG9 goal is to align the same compiler in the different host
> >> >>  development environment. It can replace VS or GCC compiler. On
> >> >>  Windows Host, I verify VS debugger for the source level debug. On
> >> >>  Linux host, I have not verified llvm debugger. I will investigate
> >> >>  the debugger solution for OVMF in Linux host.
> >> >
> >> > We are not asking you to throw out this toolchain profile.
> >> >
> >> > We are saying that since the functionality it provides is completely
> >> > unrelated to that of CLANG38, it should not be named in a way that
> >> > suggests it is merely a revision update.
> >> >
> >> > /
> >> >    Leif
> >> >
> >> >> Thanks
> >> >> Liming
> >> >> From: afish@apple.com <afish@apple.com>
> >> >> Sent: Saturday, October 26, 2019 2:45 AM
> >> >> To: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>
> >> >> Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L
> ><jordan.l.justen@intel.com>
> >> >> Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9
> >tool chain
> >> >>
> >> >> Liming,
> >> >>
> >> >> Sorry I missed this mail. Thanks for the info! I was doing some research
> >into this too and now I think I finally understand. I think the name for the tool
> >chain really confused me and we should think about changing the name.
> >> >>
> >> >> From what I understand CLANG9 means produce PE/COFF directly and
> >used the PDB debugging format. I see from the llvm site that the linker can
> >produce PDB directly as you mention. This all makes sense to me now as LLVM
> >tries to make it easy to be a drop in replacement for VC++ or GCC. So this tool
> >chain is designed to be able to cross build a "Windows App" on a Linux or
> >macOS. It also looks like the llvm debugger, lldb, is lagging in its support for
> >PDB based debugging.
> >> >>
> >> >>
> >> >> Anyway I think Leif and I agree the toolchain name is very confusing. I'd
> >rather see it called CLANG9_WIN or CLANG_PDB.
> >> >>
> >> >>
> >> >> On Oct 18, 2019, at 7:27 AM, Liming Gao
> ><liming.gao@intel.com<mailto:liming.gao@intel.com>> wrote:
> >> >>
> >> >> Andrew:
> >> >> Here is the cover letter on CLANG9 introduction.
> >https://edk2.groups.io/g/devel/message/49157
> >> >>
> >> >> 1)      Yes. CLANG9 tool chain is added to directly generate PE/COFF image
> >(EFI image).
> >> >> This tool chain uses LLVM clang C compiler and lld linker, generates
> >PE/COFF
> >> >> image and PDB compatible debug symbol format. Now, it supports
> >IA32/X64 Archs.
> >> >> LLVM clang C compiler and lld linker are the standalone tool set. They
> >don’t depend other lib to generate PE/COFF image.
> >> >>
> >> >> 2)      Yes. CLANG9 is the cross OS tool chain. It can work on
> >Windows/Linux/Mac host OS.
> >> >> LLVM LLD linker uses Windows style arguments. I verify CLANG9 for
> >Ovmf3264 in Windows/Linux host OS.
> >> >>
> >> >>
> >> >> On Linux can you source level debug Ovmf?
> >> >>
> >> >>
> >> >> 3)     This patch enables WinHost in Windows. It doesn’t enable UnixHost.
> >Now, EmulatorPkg with CLANG9 only works on Windows Host.
> >> >> This patch can make other modules pass build in Windows/Linux/Mac
> >only if LLVM9 tool set is installed.
> >> >> But, the generated image may not work on Linux/Mac. I agree below
> >linker flags are specific to windows host.
> >> >> So, I suggest to add the conditional statement of $(WIN_HOST_BUILD)
> >== TRUE for them.
> >> >>
> >> >>
> >> >> For the EmulatorPkg the Host is a native App for that OS you build on, but
> >it seems like CLANG9 is targeted to build Windows Apps. I'm not sure  but you
> >might be able to override all the linker commands to build a native app, or just
> >use the system linker for the Host?
> >> >>
> >> >> I'm not sure how well debugging will work mixing PDB and DWARF
> >symbol formats?
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Andrew Fish
> >> >>
> >> >>
> >> >>
> >> >> !if $(WIN_HOST_BUILD) == TRUE
> >> >>  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
> >/SUBSYSTEM:CONSOLE
> >> >>  GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
> >/EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> >> >>  GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
> >/EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> >> >> !endif
> >> >>
> >> >> Thanks
> >> >> Liming
> >> >> From: afish@apple.com<mailto:afish@apple.com>
> ><afish@apple.com<mailto:afish@apple.com>>
> >> >> Sent: Friday, October 18, 2019 1:15 AM
> >> >> To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> >> >> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>;
> >devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Justen, Jordan L
> ><jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
> >> >> Subject: Re: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
> >> >>
> >> >> Ray,
> >> >>
> >> >> Sorry I'm coming a little late to this and I'm confused. I have some
> >questions?
> >> >> 1) Does CLANG9 imply CLANGPE?
> >> >> 2) Does CLANGPE work on Linux and macOS? Can you pass the Windows
> >style arguments to CLANGPE linker on Linux and macOS?
> >> >> 3) For the EmulatorPkg don't you have the extra requirement that
> >compiler needs a standard C lib (or platform specific libs) to function?
> >> >>       a) GCC:*_CLANG9_*_DLINK_FLAGS in EmulatorPkg.dsc seems to
> >imply the Linux and macOS systems will have a Windows SKD dir and a lot of
> >Windows DLLs? Does all that come when you install CLANG9 when you install
> >it on Linux or macOS?
> >> >>
> >> >>
> >> >>
> >> >> So I guess I'm asking is the linker really the same for CLANG9 on all
> >systems? I guess the answer could be yes, but it seems the C lib for the Host
> >App is still an App for that OS and is OS dependent?
> >> >>
> >> >>
> >> >>
> >> >> Sorry if I'm missing something fundamental and this is a dumb question.
> >> >>
> >> >>
> >> >>
> >> >> Thanks,
> >> >>
> >> >>
> >> >>
> >> >> Andrew Fish
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On Oct 17, 2019, at 12:27 AM, Ni, Ray
> ><ray.ni@intel.com<mailto:ray.ni@intel.com>> wrote:
> >> >>
> >> >> Liming,
> >> >> Emulator is using a generic SEC module. The host specific module is called
> >"Host".
> >> >> So I prefer to change the macro to "WIN_HOST_BUILD", with this change,
> >Reviewed-by: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> >> >>
> >> >>
> >> >>
> >> >> -----Original Message-----
> >> >> From: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> >> >> Sent: Thursday, October 17, 2019 2:56 PM
> >> >> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> >> >> Cc: Justen, Jordan L
> ><jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>; Andrew
> >Fish
> >> >> <afish@apple.com<mailto:afish@apple.com>>; Ni, Ray
> ><ray.ni@intel.com<mailto:ray.ni@intel.com>>
> >> >> Subject: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
> >> >>
> >> >> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
> >> >> 1. Add WIN_SEC_BUILD macro check for CLANG9 tool chain build -p
> >> >> EmulatorPkg\EmulatorPkg.dsc -a IA32 -DWIN_SEC_BUILD=TRUE -t
> >CLANG9
> >> >> build -p EmulatorPkg\EmulatorPkg.dsc -a X64 -DWIN_SEC_BUILD=TRUE -t
> >> >> CLANG9 2. Append CLANG CC and LINK flags to generate windows HOST.
> >> >> 3. Fix WinHost issue to call GetProcessAffinityMask() API.
> >> >>  The input parameter should be UINTN pointer instead of UINT32 pointer.
> >> >>
> >> >> Cc: Jordan Justen
> ><jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
> >> >> Cc: Andrew Fish <afish@apple.com<mailto:afish@apple.com>>
> >> >> Cc: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> >> >> Signed-off-by: Liming Gao
> ><liming.gao@intel.com<mailto:liming.gao@intel.com>>
> >> >> ---
> >> >> EmulatorPkg/Win/Host/WinHost.c   | 6 +++---
> >> >> EmulatorPkg/EmulatorPkg.dsc      | 7 ++++++-
> >> >> EmulatorPkg/Win/Host/WinHost.inf | 6 ++++++
> >> >> 3 files changed, 15 insertions(+), 4 deletions(-)
> >> >>
> >> >> diff --git a/EmulatorPkg/Win/Host/WinHost.c
> >> >> b/EmulatorPkg/Win/Host/WinHost.c index 9aba3c8959..e40ce32548
> >100644
> >> >> --- a/EmulatorPkg/Win/Host/WinHost.c
> >> >> +++ b/EmulatorPkg/Win/Host/WinHost.c
> >> >> @@ -356,7 +356,7 @@ Returns:
> >> >> INTN
> >> >> EFIAPI
> >> >> main (
> >> >> -  IN  INTN  Argc,
> >> >> +  IN  INT  Argc,
> >> >>  IN  CHAR8 **Argv,
> >> >>  IN  CHAR8 **Envp
> >> >>  )
> >> >> @@ -391,8 +391,8 @@ Returns:
> >> >>  VOID                  *SecFile;
> >> >>  CHAR16                *MemorySizeStr;
> >> >>  CHAR16                *FirmwareVolumesStr;
> >> >> -  UINT32                ProcessAffinityMask;
> >> >> -  UINT32                SystemAffinityMask;
> >> >> +  UINTN                 ProcessAffinityMask;
> >> >> +  UINTN                 SystemAffinityMask;
> >> >>  INT32                 LowBit;
> >> >>
> >> >>  //
> >> >> diff --git a/EmulatorPkg/EmulatorPkg.dsc
> >b/EmulatorPkg/EmulatorPkg.dsc
> >> >> index 20f1187713..72532f5daf 100644
> >> >> --- a/EmulatorPkg/EmulatorPkg.dsc
> >> >> +++ b/EmulatorPkg/EmulatorPkg.dsc
> >> >> @@ -237,9 +237,10 @@
> >> >>
> >> >> [Components]
> >> >> !if "IA32" in $(ARCH) || "X64" in $(ARCH)
> >> >> -  !if "MSFT" in $(FAMILY)
> >> >> +  !if "MSFT" in $(FAMILY) || $(WIN_SEC_BUILD) == TRUE
> >> >>    ##
> >> >>    #  Emulator, OS WIN application
> >> >> +    #  CLANG9 is cross OS tool chain. It depends on WIN_SEC_BUILD
> >macro.
> >> >>    ##
> >> >>    EmulatorPkg/Win/Host/WinHost.inf
> >> >>  !else
> >> >> @@ -419,7 +420,11 @@
> >> >>
> >> >>  MSFT:DEBUG_*_*_CC_FLAGS = /Od /Oy-
> >> >>  MSFT:NOOPT_*_*_CC_FLAGS = /Od /Oy-
> >> >> +  GCC:DEBUG_CLANG9_*_CC_FLAGS =-O0 -Wno-unused-command-
> >line-
> >> >> argument
> >> >> + -Wno-incompatible-pointer-types -Wno-enum-conversion
> >> >> + -Wno-incompatible-pointer-types -Wno-sometimes-uninitialized
> >> >> + -Wno-constant-conversion -Wno-main-return-type
> >> >>
> >> >>  MSFT:*_*_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
> >> >> /SUBSYSTEM:CONSOLE
> >> >>  MSFT:DEBUG_*_*_DLINK_FLAGS =
> >> >> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> >> >>  MSFT:NOOPT_*_*_DLINK_FLAGS =
> >> >> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> >> >> +  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
> >> >> /SUBSYSTEM:CONSOLE
> >> >> +  GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
> >> >> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> >> >> + GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
> >> >> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> >> >> diff --git a/EmulatorPkg/Win/Host/WinHost.inf
> >> >> b/EmulatorPkg/Win/Host/WinHost.inf
> >> >> index 631d5a6470..1adca10d79 100644
> >> >> --- a/EmulatorPkg/Win/Host/WinHost.inf
> >> >> +++ b/EmulatorPkg/Win/Host/WinHost.inf
> >> >> @@ -95,3 +95,9 @@
> >> >>  MSFT:*_VS2017_X64_DLINK_FLAGS      =
> >> >> /LIBPATH:"%VCToolsInstallDir%lib\x64"
> >> >> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
> >> >> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
> >> >> /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP
> >> >> /OPT:REF /DEBUG /MACHINE:AMD64 /LTCG Kernel32.lib MSVCRTD.lib
> >> >> vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib Winmm.lib Advapi32.lib
> >> >>  MSFT:*_*_X64_ASM_FLAGS            == /nologo /W3 /WX /c /Cx /Zd /W0
> >/Zi
> >> >>  MSFT:*_*_X64_ASMLINK_FLAGS        == /link /nologo
> >> >> +
> >> >> +  GCC:*_CLANG9_X64_DLINK_FLAGS ==
> >> >> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
> >> >> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> >> >> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
> >> >> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
> >> >> /LIBPATH:"%VCToolsInstallDir%lib\x64"   /NOLOGO
> >/SUBSYSTEM:CONSOLE
> >> >> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:AMD64
> >> >> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
> >> >> Winmm.lib Advapi32.lib /lldmap
> >> >> /EXPORT:InitializeDriver=_ModuleEntryPoint
> >> >> +  GCC:*_CLANG9_X64_CC_FLAGS == -m64 -g -fshort-wchar
> >> >> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
> >> >> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D
> >UNICODE
> >> >> -D
> >> >> + _CRT_SECURE_NO_DEPRECATE
> >> >> +
> >> >> +  GCC:*_CLANG9_IA32_DLINK_FLAGS ==
> >> >> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
> >> >> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> >> >> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86"
> >> >> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86"
> >> >> /LIBPATH:"%VCToolsInstallDir%ib\x86"   /NOLOGO
> >/SUBSYSTEM:CONSOLE
> >> >> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:I386
> >> >> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
> >> >> Winmm.lib Advapi32.lib /lldmap
> >> >> /EXPORT:InitializeDriver=_ModuleEntryPoint
> >> >> +  GCC:*_CLANG9_IA32_CC_FLAGS == -m32 -g -fshort-wchar
> >> >> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
> >> >> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D
> >UNICODE
> >> >> -D
> >> >> + _CRT_SECURE_NO_DEPRECATE
> >> >> --
> >> >> 2.13.0.windows.1
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >>
> >
> >

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

[Leif Lindholm]

On Fri, Nov 08, 2019 at 03:34:59AM +0000, Ni, Ray wrote:
> Liming,
> PE is UEFI spec required executable binary format. I like CLANGPDB
> more than CLANGPE given LLVM may generate DRAWF debug symbol even
> when generating PE.

Just a comment here to point out that while (as I stated in reply to
Liming) my preference would be CLANGPE, I see the logic in the above,
and would be happy with either.

(My reason for preferring CLANGPE is not exactly techincal - I just
expect more people to know what PE is than who know what PDB is.)

Regards,

Leif

> > -----Original Message-----
> > From: Gao, Liming <liming.gao@intel.com>
> > Sent: Friday, November 8, 2019 9:50 AM
> > To: devel@edk2.groups.io; leif.lindholm@linaro.org; Andrew Fish <afish@apple.com>
> > Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>; Gao, Liming <liming.gao@intel.com>; Shi,
> > Steven <steven.shi@intel.com>
> > Subject: RE: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
> > 
> > Andrew and Leif:
> >   Thanks for your comment. CLANG9 is different from CLANG38. And, CLANG9 will support LLVM9 or the above.
> >   So, this tool chain should have the specific word for its purpose, and remove the version 9 to avoid the confuse.
> > 
> >   I prefer the tool chain name as CLANGPE or CLANGPDB. CLANGPE may be better. Now, CLANG9 tool chain
> >   build rule family just uses CLANGPE. CLANGPE lets user know this tool chain generates PE/COFF image.
> >   And, PE/COFF image debug symbol is PDB. So, PE also means PDB.
> > 
> >   Last, I just review the changes. Tool chain name update is not big. If you accept CLANGPE as tool chain name,
> >   I will send the patch soon to catch 201911 stable tag.
> > 
> > Thanks
> > Liming
> > >-----Original Message-----
> > >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Leif
> > >Lindholm
> > >Sent: Friday, November 08, 2019 2:37 AM
> > >To: Andrew Fish <afish@apple.com>
> > >Cc: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>; Ni, Ray
> > ><ray.ni@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>
> > >Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool
> > >chain
> > >
> > >Hi Andrew,
> > >
> > >Yeah, I'm pretty easy with regards to what we change it to.
> > >Although if we're bikeshedding, I would prefer not using _ in the
> > >toolchain profile name.
> > >
> > >I'm ... optimistic ... it won't break any of my existing scripts, but
> > >since the build system uses it as a
> > ><toolchain profile>_<architecture>_<build target> separator, it would
> > >be nice if we didn't risk confusion there.
> > >
> > >(I would be totally happy with PECLANG, CLANGPE, PDBCLANG, CLANGPDB or
> > >something along those lines.)
> > >
> > >Regards,
> > >
> > >Leif
> > >
> > >On Thu, Nov 07, 2019 at 11:54:04AM -0600, Andrew Fish wrote:
> > >> Leif,
> > >>
> > >> I think I proposed CLANG_PDB or CLANG_PECOFF. I seem to like
> > >CLANG_PDB as assuming the PDE debugging experience is awesome/exists
> > >on Linux and macOS is not a given.
> > >>
> > >> Thanks,
> > >>
> > >> Andrew Fish
> > >>
> > >> > On Nov 7, 2019, at 11:19 AM, Leif Lindholm <leif.lindholm@linaro.org>
> > >wrote:
> > >> >
> > >> > Oops, sorry, missed this in search.
> > >> >
> > >> > On Wed, Oct 30, 2019 at 03:43:44PM +0000, Liming Gao wrote:
> > >> >> Andrew:
> > >> >>
> > >> >>  I prefer to keep short CLANG9 as the tool chain name. I add wiki
> > >> >>  page
> > >> >>  https://github.com/tianocore/tianocore.github.io/wiki/CLANG9-Tools-
> > >Chain
> > >> >>  to introduce it.
> > >> >
> > >> > Why should users be expected to go and read documentation in order to
> > >> > learn that fundamental and incompatible changes to output and debug
> > >> > format has been made as part of what looks like a simple version bump?
> > >> >
> > >> >>  And, we have CLANG38 tool chain. It generates ELF
> > >> >>  image and DWARF debug symbol format. It can work with LLVM 9.0
> > >> >>  release. Current tool chain tag name includes compiler name and
> > >> >>  version. There is no specific info in the tool chain name. The
> > >> >>  developer can get the more tool chain information from wiki page.
> > >> >
> > >> > We aleady have the problem that people think they need to use GCC5 to
> > >> > build EDK2 since that is the highest named GCC toolchain profile.
> > >> >
> > >> > Let's not make this situation *worse* by setting up a multidimensional
> > >> > feature matrix, based off random numerical values.
> > >> >
> > >> > So say that we next have a pressing need to create a new toolchain
> > >> > profile for clang 10, using the old ELF mechanism. Are you then
> > >> > suggesting we set up a table on said wiki page where people have to go
> > >> > and look up what the object and debug formats are for each CLANG##
> > >> > toolchain profile?
> > >> >
> > >> > And what if you then end up needing to do the same for the PDB
> > >> > flavour?
> > >> >
> > >> >>  CLANG9 is designed to support Emulator for Windows host only.
> > >> >
> > >> > Which is why it makes no sense to name it as a successor of
> > >> > CLANG38.
> > >> >
> > >> >>  CLANG38 may be used for Emulator in Linux or Mac. I don’t
> > >> >>  try it before.
> > >> >>
> > >> >>  CLANG9 goal is to align the same compiler in the different host
> > >> >>  development environment. It can replace VS or GCC compiler. On
> > >> >>  Windows Host, I verify VS debugger for the source level debug. On
> > >> >>  Linux host, I have not verified llvm debugger. I will investigate
> > >> >>  the debugger solution for OVMF in Linux host.
> > >> >
> > >> > We are not asking you to throw out this toolchain profile.
> > >> >
> > >> > We are saying that since the functionality it provides is completely
> > >> > unrelated to that of CLANG38, it should not be named in a way that
> > >> > suggests it is merely a revision update.
> > >> >
> > >> > /
> > >> >    Leif
> > >> >
> > >> >> Thanks
> > >> >> Liming
> > >> >> From: afish@apple.com <afish@apple.com>
> > >> >> Sent: Saturday, October 26, 2019 2:45 AM
> > >> >> To: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>
> > >> >> Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L
> > ><jordan.l.justen@intel.com>
> > >> >> Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9
> > >tool chain
> > >> >>
> > >> >> Liming,
> > >> >>
> > >> >> Sorry I missed this mail. Thanks for the info! I was doing some research
> > >into this too and now I think I finally understand. I think the name for the tool
> > >chain really confused me and we should think about changing the name.
> > >> >>
> > >> >> From what I understand CLANG9 means produce PE/COFF directly and
> > >used the PDB debugging format. I see from the llvm site that the linker can
> > >produce PDB directly as you mention. This all makes sense to me now as LLVM
> > >tries to make it easy to be a drop in replacement for VC++ or GCC. So this tool
> > >chain is designed to be able to cross build a "Windows App" on a Linux or
> > >macOS. It also looks like the llvm debugger, lldb, is lagging in its support for
> > >PDB based debugging.
> > >> >>
> > >> >>
> > >> >> Anyway I think Leif and I agree the toolchain name is very confusing. I'd
> > >rather see it called CLANG9_WIN or CLANG_PDB.
> > >> >>
> > >> >>
> > >> >> On Oct 18, 2019, at 7:27 AM, Liming Gao
> > ><liming.gao@intel.com<mailto:liming.gao@intel.com>> wrote:
> > >> >>
> > >> >> Andrew:
> > >> >> Here is the cover letter on CLANG9 introduction.
> > >https://edk2.groups.io/g/devel/message/49157
> > >> >>
> > >> >> 1)      Yes. CLANG9 tool chain is added to directly generate PE/COFF image
> > >(EFI image).
> > >> >> This tool chain uses LLVM clang C compiler and lld linker, generates
> > >PE/COFF
> > >> >> image and PDB compatible debug symbol format. Now, it supports
> > >IA32/X64 Archs.
> > >> >> LLVM clang C compiler and lld linker are the standalone tool set. They
> > >don’t depend other lib to generate PE/COFF image.
> > >> >>
> > >> >> 2)      Yes. CLANG9 is the cross OS tool chain. It can work on
> > >Windows/Linux/Mac host OS.
> > >> >> LLVM LLD linker uses Windows style arguments. I verify CLANG9 for
> > >Ovmf3264 in Windows/Linux host OS.
> > >> >>
> > >> >>
> > >> >> On Linux can you source level debug Ovmf?
> > >> >>
> > >> >>
> > >> >> 3)     This patch enables WinHost in Windows. It doesn’t enable UnixHost.
> > >Now, EmulatorPkg with CLANG9 only works on Windows Host.
> > >> >> This patch can make other modules pass build in Windows/Linux/Mac
> > >only if LLVM9 tool set is installed.
> > >> >> But, the generated image may not work on Linux/Mac. I agree below
> > >linker flags are specific to windows host.
> > >> >> So, I suggest to add the conditional statement of $(WIN_HOST_BUILD)
> > >== TRUE for them.
> > >> >>
> > >> >>
> > >> >> For the EmulatorPkg the Host is a native App for that OS you build on, but
> > >it seems like CLANG9 is targeted to build Windows Apps. I'm not sure  but you
> > >might be able to override all the linker commands to build a native app, or just
> > >use the system linker for the Host?
> > >> >>
> > >> >> I'm not sure how well debugging will work mixing PDB and DWARF
> > >symbol formats?
> > >> >>
> > >> >> Thanks,
> > >> >>
> > >> >> Andrew Fish
> > >> >>
> > >> >>
> > >> >>
> > >> >> !if $(WIN_HOST_BUILD) == TRUE
> > >> >>  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
> > >/SUBSYSTEM:CONSOLE
> > >> >>  GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
> > >/EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> > >> >>  GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
> > >/EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> > >> >> !endif
> > >> >>
> > >> >> Thanks
> > >> >> Liming
> > >> >> From: afish@apple.com<mailto:afish@apple.com>
> > ><afish@apple.com<mailto:afish@apple.com>>
> > >> >> Sent: Friday, October 18, 2019 1:15 AM
> > >> >> To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > >> >> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>;
> > >devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Justen, Jordan L
> > ><jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
> > >> >> Subject: Re: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
> > >> >>
> > >> >> Ray,
> > >> >>
> > >> >> Sorry I'm coming a little late to this and I'm confused. I have some
> > >questions?
> > >> >> 1) Does CLANG9 imply CLANGPE?
> > >> >> 2) Does CLANGPE work on Linux and macOS? Can you pass the Windows
> > >style arguments to CLANGPE linker on Linux and macOS?
> > >> >> 3) For the EmulatorPkg don't you have the extra requirement that
> > >compiler needs a standard C lib (or platform specific libs) to function?
> > >> >>       a) GCC:*_CLANG9_*_DLINK_FLAGS in EmulatorPkg.dsc seems to
> > >imply the Linux and macOS systems will have a Windows SKD dir and a lot of
> > >Windows DLLs? Does all that come when you install CLANG9 when you install
> > >it on Linux or macOS?
> > >> >>
> > >> >>
> > >> >>
> > >> >> So I guess I'm asking is the linker really the same for CLANG9 on all
> > >systems? I guess the answer could be yes, but it seems the C lib for the Host
> > >App is still an App for that OS and is OS dependent?
> > >> >>
> > >> >>
> > >> >>
> > >> >> Sorry if I'm missing something fundamental and this is a dumb question.
> > >> >>
> > >> >>
> > >> >>
> > >> >> Thanks,
> > >> >>
> > >> >>
> > >> >>
> > >> >> Andrew Fish
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >> On Oct 17, 2019, at 12:27 AM, Ni, Ray
> > ><ray.ni@intel.com<mailto:ray.ni@intel.com>> wrote:
> > >> >>
> > >> >> Liming,
> > >> >> Emulator is using a generic SEC module. The host specific module is called
> > >"Host".
> > >> >> So I prefer to change the macro to "WIN_HOST_BUILD", with this change,
> > >Reviewed-by: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > >> >>
> > >> >>
> > >> >>
> > >> >> -----Original Message-----
> > >> >> From: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > >> >> Sent: Thursday, October 17, 2019 2:56 PM
> > >> >> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> > >> >> Cc: Justen, Jordan L
> > ><jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>; Andrew
> > >Fish
> > >> >> <afish@apple.com<mailto:afish@apple.com>>; Ni, Ray
> > ><ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > >> >> Subject: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
> > >> >>
> > >> >> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
> > >> >> 1. Add WIN_SEC_BUILD macro check for CLANG9 tool chain build -p
> > >> >> EmulatorPkg\EmulatorPkg.dsc -a IA32 -DWIN_SEC_BUILD=TRUE -t
> > >CLANG9
> > >> >> build -p EmulatorPkg\EmulatorPkg.dsc -a X64 -DWIN_SEC_BUILD=TRUE -t
> > >> >> CLANG9 2. Append CLANG CC and LINK flags to generate windows HOST.
> > >> >> 3. Fix WinHost issue to call GetProcessAffinityMask() API.
> > >> >>  The input parameter should be UINTN pointer instead of UINT32 pointer.
> > >> >>
> > >> >> Cc: Jordan Justen
> > ><jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
> > >> >> Cc: Andrew Fish <afish@apple.com<mailto:afish@apple.com>>
> > >> >> Cc: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > >> >> Signed-off-by: Liming Gao
> > ><liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > >> >> ---
> > >> >> EmulatorPkg/Win/Host/WinHost.c   | 6 +++---
> > >> >> EmulatorPkg/EmulatorPkg.dsc      | 7 ++++++-
> > >> >> EmulatorPkg/Win/Host/WinHost.inf | 6 ++++++
> > >> >> 3 files changed, 15 insertions(+), 4 deletions(-)
> > >> >>
> > >> >> diff --git a/EmulatorPkg/Win/Host/WinHost.c
> > >> >> b/EmulatorPkg/Win/Host/WinHost.c index 9aba3c8959..e40ce32548
> > >100644
> > >> >> --- a/EmulatorPkg/Win/Host/WinHost.c
> > >> >> +++ b/EmulatorPkg/Win/Host/WinHost.c
> > >> >> @@ -356,7 +356,7 @@ Returns:
> > >> >> INTN
> > >> >> EFIAPI
> > >> >> main (
> > >> >> -  IN  INTN  Argc,
> > >> >> +  IN  INT  Argc,
> > >> >>  IN  CHAR8 **Argv,
> > >> >>  IN  CHAR8 **Envp
> > >> >>  )
> > >> >> @@ -391,8 +391,8 @@ Returns:
> > >> >>  VOID                  *SecFile;
> > >> >>  CHAR16                *MemorySizeStr;
> > >> >>  CHAR16                *FirmwareVolumesStr;
> > >> >> -  UINT32                ProcessAffinityMask;
> > >> >> -  UINT32                SystemAffinityMask;
> > >> >> +  UINTN                 ProcessAffinityMask;
> > >> >> +  UINTN                 SystemAffinityMask;
> > >> >>  INT32                 LowBit;
> > >> >>
> > >> >>  //
> > >> >> diff --git a/EmulatorPkg/EmulatorPkg.dsc
> > >b/EmulatorPkg/EmulatorPkg.dsc
> > >> >> index 20f1187713..72532f5daf 100644
> > >> >> --- a/EmulatorPkg/EmulatorPkg.dsc
> > >> >> +++ b/EmulatorPkg/EmulatorPkg.dsc
> > >> >> @@ -237,9 +237,10 @@
> > >> >>
> > >> >> [Components]
> > >> >> !if "IA32" in $(ARCH) || "X64" in $(ARCH)
> > >> >> -  !if "MSFT" in $(FAMILY)
> > >> >> +  !if "MSFT" in $(FAMILY) || $(WIN_SEC_BUILD) == TRUE
> > >> >>    ##
> > >> >>    #  Emulator, OS WIN application
> > >> >> +    #  CLANG9 is cross OS tool chain. It depends on WIN_SEC_BUILD
> > >macro.
> > >> >>    ##
> > >> >>    EmulatorPkg/Win/Host/WinHost.inf
> > >> >>  !else
> > >> >> @@ -419,7 +420,11 @@
> > >> >>
> > >> >>  MSFT:DEBUG_*_*_CC_FLAGS = /Od /Oy-
> > >> >>  MSFT:NOOPT_*_*_CC_FLAGS = /Od /Oy-
> > >> >> +  GCC:DEBUG_CLANG9_*_CC_FLAGS =-O0 -Wno-unused-command-
> > >line-
> > >> >> argument
> > >> >> + -Wno-incompatible-pointer-types -Wno-enum-conversion
> > >> >> + -Wno-incompatible-pointer-types -Wno-sometimes-uninitialized
> > >> >> + -Wno-constant-conversion -Wno-main-return-type
> > >> >>
> > >> >>  MSFT:*_*_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
> > >> >> /SUBSYSTEM:CONSOLE
> > >> >>  MSFT:DEBUG_*_*_DLINK_FLAGS =
> > >> >> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> > >> >>  MSFT:NOOPT_*_*_DLINK_FLAGS =
> > >> >> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> > >> >> +  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
> > >> >> /SUBSYSTEM:CONSOLE
> > >> >> +  GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
> > >> >> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> > >> >> + GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
> > >> >> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> > >> >> diff --git a/EmulatorPkg/Win/Host/WinHost.inf
> > >> >> b/EmulatorPkg/Win/Host/WinHost.inf
> > >> >> index 631d5a6470..1adca10d79 100644
> > >> >> --- a/EmulatorPkg/Win/Host/WinHost.inf
> > >> >> +++ b/EmulatorPkg/Win/Host/WinHost.inf
> > >> >> @@ -95,3 +95,9 @@
> > >> >>  MSFT:*_VS2017_X64_DLINK_FLAGS      =
> > >> >> /LIBPATH:"%VCToolsInstallDir%lib\x64"
> > >> >> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
> > >> >> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
> > >> >> /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP
> > >> >> /OPT:REF /DEBUG /MACHINE:AMD64 /LTCG Kernel32.lib MSVCRTD.lib
> > >> >> vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib Winmm.lib Advapi32.lib
> > >> >>  MSFT:*_*_X64_ASM_FLAGS            == /nologo /W3 /WX /c /Cx /Zd /W0
> > >/Zi
> > >> >>  MSFT:*_*_X64_ASMLINK_FLAGS        == /link /nologo
> > >> >> +
> > >> >> +  GCC:*_CLANG9_X64_DLINK_FLAGS ==
> > >> >> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
> > >> >> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> > >> >> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
> > >> >> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
> > >> >> /LIBPATH:"%VCToolsInstallDir%lib\x64"   /NOLOGO
> > >/SUBSYSTEM:CONSOLE
> > >> >> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:AMD64
> > >> >> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
> > >> >> Winmm.lib Advapi32.lib /lldmap
> > >> >> /EXPORT:InitializeDriver=_ModuleEntryPoint
> > >> >> +  GCC:*_CLANG9_X64_CC_FLAGS == -m64 -g -fshort-wchar
> > >> >> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
> > >> >> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D
> > >UNICODE
> > >> >> -D
> > >> >> + _CRT_SECURE_NO_DEPRECATE
> > >> >> +
> > >> >> +  GCC:*_CLANG9_IA32_DLINK_FLAGS ==
> > >> >> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
> > >> >> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> > >> >> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86"
> > >> >> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86"
> > >> >> /LIBPATH:"%VCToolsInstallDir%ib\x86"   /NOLOGO
> > >/SUBSYSTEM:CONSOLE
> > >> >> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:I386
> > >> >> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
> > >> >> Winmm.lib Advapi32.lib /lldmap
> > >> >> /EXPORT:InitializeDriver=_ModuleEntryPoint
> > >> >> +  GCC:*_CLANG9_IA32_CC_FLAGS == -m32 -g -fshort-wchar
> > >> >> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
> > >> >> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D
> > >UNICODE
> > >> >> -D
> > >> >> + _CRT_SECURE_NO_DEPRECATE
> > >> >> --
> > >> >> 2.13.0.windows.1
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >> >
> > >>
> > >
> > >
> 

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

[Andrew Fish]

Either works for me too. I like the PDE ending a little more, but agree it is a little more obscure.
> On Nov 11, 2019, at 8:39 AM, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> 
> On Fri, Nov 08, 2019 at 03:34:59AM +0000, Ni, Ray wrote:
>> Liming,
>> PE is UEFI spec required executable binary format. I like CLANGPDB
>> more than CLANGPE given LLVM may generate DRAWF debug symbol even
>> when generating PE.
> 
> Just a comment here to point out that while (as I stated in reply to
> Liming) my preference would be CLANGPE, I see the logic in the above,
> and would be happy with either.
> 
> (My reason for preferring CLANGPE is not exactly techincal - I just
> expect more people to know what PE is than who know what PDB is.)
> 
> Regards,
> 
> Leif
> 
>>> -----Original Message-----
>>> From: Gao, Liming <liming.gao@intel.com>
>>> Sent: Friday, November 8, 2019 9:50 AM
>>> To: devel@edk2.groups.io; leif.lindholm@linaro.org; Andrew Fish <afish@apple.com>
>>> Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>; Gao, Liming <liming.gao@intel.com>; Shi,
>>> Steven <steven.shi@intel.com>
>>> Subject: RE: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
>>> 
>>> Andrew and Leif:
>>>  Thanks for your comment. CLANG9 is different from CLANG38. And, CLANG9 will support LLVM9 or the above.
>>>  So, this tool chain should have the specific word for its purpose, and remove the version 9 to avoid the confuse.
>>> 
>>>  I prefer the tool chain name as CLANGPE or CLANGPDB. CLANGPE may be better. Now, CLANG9 tool chain
>>>  build rule family just uses CLANGPE. CLANGPE lets user know this tool chain generates PE/COFF image.
>>>  And, PE/COFF image debug symbol is PDB. So, PE also means PDB.
>>> 
>>>  Last, I just review the changes. Tool chain name update is not big. If you accept CLANGPE as tool chain name,
>>>  I will send the patch soon to catch 201911 stable tag.
>>> 
>>> Thanks
>>> Liming
>>>> -----Original Message-----
>>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Leif
>>>> Lindholm
>>>> Sent: Friday, November 08, 2019 2:37 AM
>>>> To: Andrew Fish <afish@apple.com>
>>>> Cc: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>; Ni, Ray
>>>> <ray.ni@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>
>>>> Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool
>>>> chain
>>>> 
>>>> Hi Andrew,
>>>> 
>>>> Yeah, I'm pretty easy with regards to what we change it to.
>>>> Although if we're bikeshedding, I would prefer not using _ in the
>>>> toolchain profile name.
>>>> 
>>>> I'm ... optimistic ... it won't break any of my existing scripts, but
>>>> since the build system uses it as a
>>>> <toolchain profile>_<architecture>_<build target> separator, it would
>>>> be nice if we didn't risk confusion there.
>>>> 
>>>> (I would be totally happy with PECLANG, CLANGPE, PDBCLANG, CLANGPDB or
>>>> something along those lines.)
>>>> 
>>>> Regards,
>>>> 
>>>> Leif
>>>> 
>>>> On Thu, Nov 07, 2019 at 11:54:04AM -0600, Andrew Fish wrote:
>>>>> Leif,
>>>>> 
>>>>> I think I proposed CLANG_PDB or CLANG_PECOFF. I seem to like
>>>> CLANG_PDB as assuming the PDE debugging experience is awesome/exists
>>>> on Linux and macOS is not a given.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Andrew Fish
>>>>> 
>>>>>> On Nov 7, 2019, at 11:19 AM, Leif Lindholm <leif.lindholm@linaro.org>
>>>> wrote:
>>>>>> 
>>>>>> Oops, sorry, missed this in search.
>>>>>> 
>>>>>> On Wed, Oct 30, 2019 at 03:43:44PM +0000, Liming Gao wrote:
>>>>>>> Andrew:
>>>>>>> 
>>>>>>> I prefer to keep short CLANG9 as the tool chain name. I add wiki
>>>>>>> page
>>>>>>> https://github.com/tianocore/tianocore.github.io/wiki/CLANG9-Tools-
>>>> Chain
>>>>>>> to introduce it.
>>>>>> 
>>>>>> Why should users be expected to go and read documentation in order to
>>>>>> learn that fundamental and incompatible changes to output and debug
>>>>>> format has been made as part of what looks like a simple version bump?
>>>>>> 
>>>>>>> And, we have CLANG38 tool chain. It generates ELF
>>>>>>> image and DWARF debug symbol format. It can work with LLVM 9.0
>>>>>>> release. Current tool chain tag name includes compiler name and
>>>>>>> version. There is no specific info in the tool chain name. The
>>>>>>> developer can get the more tool chain information from wiki page.
>>>>>> 
>>>>>> We aleady have the problem that people think they need to use GCC5 to
>>>>>> build EDK2 since that is the highest named GCC toolchain profile.
>>>>>> 
>>>>>> Let's not make this situation *worse* by setting up a multidimensional
>>>>>> feature matrix, based off random numerical values.
>>>>>> 
>>>>>> So say that we next have a pressing need to create a new toolchain
>>>>>> profile for clang 10, using the old ELF mechanism. Are you then
>>>>>> suggesting we set up a table on said wiki page where people have to go
>>>>>> and look up what the object and debug formats are for each CLANG##
>>>>>> toolchain profile?
>>>>>> 
>>>>>> And what if you then end up needing to do the same for the PDB
>>>>>> flavour?
>>>>>> 
>>>>>>> CLANG9 is designed to support Emulator for Windows host only.
>>>>>> 
>>>>>> Which is why it makes no sense to name it as a successor of
>>>>>> CLANG38.
>>>>>> 
>>>>>>> CLANG38 may be used for Emulator in Linux or Mac. I don’t
>>>>>>> try it before.
>>>>>>> 
>>>>>>> CLANG9 goal is to align the same compiler in the different host
>>>>>>> development environment. It can replace VS or GCC compiler. On
>>>>>>> Windows Host, I verify VS debugger for the source level debug. On
>>>>>>> Linux host, I have not verified llvm debugger. I will investigate
>>>>>>> the debugger solution for OVMF in Linux host.
>>>>>> 
>>>>>> We are not asking you to throw out this toolchain profile.
>>>>>> 
>>>>>> We are saying that since the functionality it provides is completely
>>>>>> unrelated to that of CLANG38, it should not be named in a way that
>>>>>> suggests it is merely a revision update.
>>>>>> 
>>>>>> /
>>>>>>   Leif
>>>>>> 
>>>>>>> Thanks
>>>>>>> Liming
>>>>>>> From: afish@apple.com <afish@apple.com>
>>>>>>> Sent: Saturday, October 26, 2019 2:45 AM
>>>>>>> To: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>
>>>>>>> Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L
>>>> <jordan.l.justen@intel.com>
>>>>>>> Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9
>>>> tool chain
>>>>>>> 
>>>>>>> Liming,
>>>>>>> 
>>>>>>> Sorry I missed this mail. Thanks for the info! I was doing some research
>>>> into this too and now I think I finally understand. I think the name for the tool
>>>> chain really confused me and we should think about changing the name.
>>>>>>> 
>>>>>>> From what I understand CLANG9 means produce PE/COFF directly and
>>>> used the PDB debugging format. I see from the llvm site that the linker can
>>>> produce PDB directly as you mention. This all makes sense to me now as LLVM
>>>> tries to make it easy to be a drop in replacement for VC++ or GCC. So this tool
>>>> chain is designed to be able to cross build a "Windows App" on a Linux or
>>>> macOS. It also looks like the llvm debugger, lldb, is lagging in its support for
>>>> PDB based debugging.
>>>>>>> 
>>>>>>> 
>>>>>>> Anyway I think Leif and I agree the toolchain name is very confusing. I'd
>>>> rather see it called CLANG9_WIN or CLANG_PDB.
>>>>>>> 
>>>>>>> 
>>>>>>> On Oct 18, 2019, at 7:27 AM, Liming Gao
>>>> <liming.gao@intel.com<mailto:liming.gao@intel.com>> wrote:
>>>>>>> 
>>>>>>> Andrew:
>>>>>>> Here is the cover letter on CLANG9 introduction.
>>>> https://edk2.groups.io/g/devel/message/49157
>>>>>>> 
>>>>>>> 1)      Yes. CLANG9 tool chain is added to directly generate PE/COFF image
>>>> (EFI image).
>>>>>>> This tool chain uses LLVM clang C compiler and lld linker, generates
>>>> PE/COFF
>>>>>>> image and PDB compatible debug symbol format. Now, it supports
>>>> IA32/X64 Archs.
>>>>>>> LLVM clang C compiler and lld linker are the standalone tool set. They
>>>> don’t depend other lib to generate PE/COFF image.
>>>>>>> 
>>>>>>> 2)      Yes. CLANG9 is the cross OS tool chain. It can work on
>>>> Windows/Linux/Mac host OS.
>>>>>>> LLVM LLD linker uses Windows style arguments. I verify CLANG9 for
>>>> Ovmf3264 in Windows/Linux host OS.
>>>>>>> 
>>>>>>> 
>>>>>>> On Linux can you source level debug Ovmf?
>>>>>>> 
>>>>>>> 
>>>>>>> 3)     This patch enables WinHost in Windows. It doesn’t enable UnixHost.
>>>> Now, EmulatorPkg with CLANG9 only works on Windows Host.
>>>>>>> This patch can make other modules pass build in Windows/Linux/Mac
>>>> only if LLVM9 tool set is installed.
>>>>>>> But, the generated image may not work on Linux/Mac. I agree below
>>>> linker flags are specific to windows host.
>>>>>>> So, I suggest to add the conditional statement of $(WIN_HOST_BUILD)
>>>> == TRUE for them.
>>>>>>> 
>>>>>>> 
>>>>>>> For the EmulatorPkg the Host is a native App for that OS you build on, but
>>>> it seems like CLANG9 is targeted to build Windows Apps. I'm not sure  but you
>>>> might be able to override all the linker commands to build a native app, or just
>>>> use the system linker for the Host?
>>>>>>> 
>>>>>>> I'm not sure how well debugging will work mixing PDB and DWARF
>>>> symbol formats?
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> 
>>>>>>> Andrew Fish
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> !if $(WIN_HOST_BUILD) == TRUE
>>>>>>> GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
>>>> /SUBSYSTEM:CONSOLE
>>>>>>> GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
>>>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>>>>>>> GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
>>>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>>>>>>> !endif
>>>>>>> 
>>>>>>> Thanks
>>>>>>> Liming
>>>>>>> From: afish@apple.com<mailto:afish@apple.com>
>>>> <afish@apple.com<mailto:afish@apple.com>>
>>>>>>> Sent: Friday, October 18, 2019 1:15 AM
>>>>>>> To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
>>>>>>> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>;
>>>> devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Justen, Jordan L
>>>> <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
>>>>>>> Subject: Re: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
>>>>>>> 
>>>>>>> Ray,
>>>>>>> 
>>>>>>> Sorry I'm coming a little late to this and I'm confused. I have some
>>>> questions?
>>>>>>> 1) Does CLANG9 imply CLANGPE?
>>>>>>> 2) Does CLANGPE work on Linux and macOS? Can you pass the Windows
>>>> style arguments to CLANGPE linker on Linux and macOS?
>>>>>>> 3) For the EmulatorPkg don't you have the extra requirement that
>>>> compiler needs a standard C lib (or platform specific libs) to function?
>>>>>>>      a) GCC:*_CLANG9_*_DLINK_FLAGS in EmulatorPkg.dsc seems to
>>>> imply the Linux and macOS systems will have a Windows SKD dir and a lot of
>>>> Windows DLLs? Does all that come when you install CLANG9 when you install
>>>> it on Linux or macOS?
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> So I guess I'm asking is the linker really the same for CLANG9 on all
>>>> systems? I guess the answer could be yes, but it seems the C lib for the Host
>>>> App is still an App for that OS and is OS dependent?
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Sorry if I'm missing something fundamental and this is a dumb question.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Andrew Fish
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Oct 17, 2019, at 12:27 AM, Ni, Ray
>>>> <ray.ni@intel.com<mailto:ray.ni@intel.com>> wrote:
>>>>>>> 
>>>>>>> Liming,
>>>>>>> Emulator is using a generic SEC module. The host specific module is called
>>>> "Host".
>>>>>>> So I prefer to change the macro to "WIN_HOST_BUILD", with this change,
>>>> Reviewed-by: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
>>>>>>> Sent: Thursday, October 17, 2019 2:56 PM
>>>>>>> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
>>>>>>> Cc: Justen, Jordan L
>>>> <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>; Andrew
>>>> Fish
>>>>>>> <afish@apple.com<mailto:afish@apple.com>>; Ni, Ray
>>>> <ray.ni@intel.com<mailto:ray.ni@intel.com>>
>>>>>>> Subject: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
>>>>>>> 
>>>>>>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
>>>>>>> 1. Add WIN_SEC_BUILD macro check for CLANG9 tool chain build -p
>>>>>>> EmulatorPkg\EmulatorPkg.dsc -a IA32 -DWIN_SEC_BUILD=TRUE -t
>>>> CLANG9
>>>>>>> build -p EmulatorPkg\EmulatorPkg.dsc -a X64 -DWIN_SEC_BUILD=TRUE -t
>>>>>>> CLANG9 2. Append CLANG CC and LINK flags to generate windows HOST.
>>>>>>> 3. Fix WinHost issue to call GetProcessAffinityMask() API.
>>>>>>> The input parameter should be UINTN pointer instead of UINT32 pointer.
>>>>>>> 
>>>>>>> Cc: Jordan Justen
>>>> <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
>>>>>>> Cc: Andrew Fish <afish@apple.com<mailto:afish@apple.com>>
>>>>>>> Cc: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
>>>>>>> Signed-off-by: Liming Gao
>>>> <liming.gao@intel.com<mailto:liming.gao@intel.com>>
>>>>>>> ---
>>>>>>> EmulatorPkg/Win/Host/WinHost.c   | 6 +++---
>>>>>>> EmulatorPkg/EmulatorPkg.dsc      | 7 ++++++-
>>>>>>> EmulatorPkg/Win/Host/WinHost.inf | 6 ++++++
>>>>>>> 3 files changed, 15 insertions(+), 4 deletions(-)
>>>>>>> 
>>>>>>> diff --git a/EmulatorPkg/Win/Host/WinHost.c
>>>>>>> b/EmulatorPkg/Win/Host/WinHost.c index 9aba3c8959..e40ce32548
>>>> 100644
>>>>>>> --- a/EmulatorPkg/Win/Host/WinHost.c
>>>>>>> +++ b/EmulatorPkg/Win/Host/WinHost.c
>>>>>>> @@ -356,7 +356,7 @@ Returns:
>>>>>>> INTN
>>>>>>> EFIAPI
>>>>>>> main (
>>>>>>> -  IN  INTN  Argc,
>>>>>>> +  IN  INT  Argc,
>>>>>>> IN  CHAR8 **Argv,
>>>>>>> IN  CHAR8 **Envp
>>>>>>> )
>>>>>>> @@ -391,8 +391,8 @@ Returns:
>>>>>>> VOID                  *SecFile;
>>>>>>> CHAR16                *MemorySizeStr;
>>>>>>> CHAR16                *FirmwareVolumesStr;
>>>>>>> -  UINT32                ProcessAffinityMask;
>>>>>>> -  UINT32                SystemAffinityMask;
>>>>>>> +  UINTN                 ProcessAffinityMask;
>>>>>>> +  UINTN                 SystemAffinityMask;
>>>>>>> INT32                 LowBit;
>>>>>>> 
>>>>>>> //
>>>>>>> diff --git a/EmulatorPkg/EmulatorPkg.dsc
>>>> b/EmulatorPkg/EmulatorPkg.dsc
>>>>>>> index 20f1187713..72532f5daf 100644
>>>>>>> --- a/EmulatorPkg/EmulatorPkg.dsc
>>>>>>> +++ b/EmulatorPkg/EmulatorPkg.dsc
>>>>>>> @@ -237,9 +237,10 @@
>>>>>>> 
>>>>>>> [Components]
>>>>>>> !if "IA32" in $(ARCH) || "X64" in $(ARCH)
>>>>>>> -  !if "MSFT" in $(FAMILY)
>>>>>>> +  !if "MSFT" in $(FAMILY) || $(WIN_SEC_BUILD) == TRUE
>>>>>>>   ##
>>>>>>>   #  Emulator, OS WIN application
>>>>>>> +    #  CLANG9 is cross OS tool chain. It depends on WIN_SEC_BUILD
>>>> macro.
>>>>>>>   ##
>>>>>>>   EmulatorPkg/Win/Host/WinHost.inf
>>>>>>> !else
>>>>>>> @@ -419,7 +420,11 @@
>>>>>>> 
>>>>>>> MSFT:DEBUG_*_*_CC_FLAGS = /Od /Oy-
>>>>>>> MSFT:NOOPT_*_*_CC_FLAGS = /Od /Oy-
>>>>>>> +  GCC:DEBUG_CLANG9_*_CC_FLAGS =-O0 -Wno-unused-command-
>>>> line-
>>>>>>> argument
>>>>>>> + -Wno-incompatible-pointer-types -Wno-enum-conversion
>>>>>>> + -Wno-incompatible-pointer-types -Wno-sometimes-uninitialized
>>>>>>> + -Wno-constant-conversion -Wno-main-return-type
>>>>>>> 
>>>>>>> MSFT:*_*_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
>>>>>>> /SUBSYSTEM:CONSOLE
>>>>>>> MSFT:DEBUG_*_*_DLINK_FLAGS =
>>>>>>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>>>>>>> MSFT:NOOPT_*_*_DLINK_FLAGS =
>>>>>>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>>>>>>> +  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
>>>>>>> /SUBSYSTEM:CONSOLE
>>>>>>> +  GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
>>>>>>> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>>>>>>> + GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
>>>>>>> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>>>>>>> diff --git a/EmulatorPkg/Win/Host/WinHost.inf
>>>>>>> b/EmulatorPkg/Win/Host/WinHost.inf
>>>>>>> index 631d5a6470..1adca10d79 100644
>>>>>>> --- a/EmulatorPkg/Win/Host/WinHost.inf
>>>>>>> +++ b/EmulatorPkg/Win/Host/WinHost.inf
>>>>>>> @@ -95,3 +95,9 @@
>>>>>>> MSFT:*_VS2017_X64_DLINK_FLAGS      =
>>>>>>> /LIBPATH:"%VCToolsInstallDir%lib\x64"
>>>>>>> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
>>>>>>> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
>>>>>>> /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP
>>>>>>> /OPT:REF /DEBUG /MACHINE:AMD64 /LTCG Kernel32.lib MSVCRTD.lib
>>>>>>> vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib Winmm.lib Advapi32.lib
>>>>>>> MSFT:*_*_X64_ASM_FLAGS            == /nologo /W3 /WX /c /Cx /Zd /W0
>>>> /Zi
>>>>>>> MSFT:*_*_X64_ASMLINK_FLAGS        == /link /nologo
>>>>>>> +
>>>>>>> +  GCC:*_CLANG9_X64_DLINK_FLAGS ==
>>>>>>> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
>>>>>>> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
>>>>>>> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
>>>>>>> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
>>>>>>> /LIBPATH:"%VCToolsInstallDir%lib\x64"   /NOLOGO
>>>> /SUBSYSTEM:CONSOLE
>>>>>>> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:AMD64
>>>>>>> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
>>>>>>> Winmm.lib Advapi32.lib /lldmap
>>>>>>> /EXPORT:InitializeDriver=_ModuleEntryPoint
>>>>>>> +  GCC:*_CLANG9_X64_CC_FLAGS == -m64 -g -fshort-wchar
>>>>>>> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
>>>>>>> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D
>>>> UNICODE
>>>>>>> -D
>>>>>>> + _CRT_SECURE_NO_DEPRECATE
>>>>>>> +
>>>>>>> +  GCC:*_CLANG9_IA32_DLINK_FLAGS ==
>>>>>>> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
>>>>>>> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
>>>>>>> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86"
>>>>>>> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86"
>>>>>>> /LIBPATH:"%VCToolsInstallDir%ib\x86"   /NOLOGO
>>>> /SUBSYSTEM:CONSOLE
>>>>>>> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:I386
>>>>>>> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
>>>>>>> Winmm.lib Advapi32.lib /lldmap
>>>>>>> /EXPORT:InitializeDriver=_ModuleEntryPoint
>>>>>>> +  GCC:*_CLANG9_IA32_CC_FLAGS == -m32 -g -fshort-wchar
>>>>>>> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
>>>>>>> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D
>>>> UNICODE
>>>>>>> -D
>>>>>>> + _CRT_SECURE_NO_DEPRECATE
>>>>>>> --
>>>>>>> 2.13.0.windows.1
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>> 

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

[Andrew Fish]

Either works for me too. I like the PDE ending a little more, but agree it is a little more obscure.
> On Nov 11, 2019, at 8:39 AM, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> 
> On Fri, Nov 08, 2019 at 03:34:59AM +0000, Ni, Ray wrote:
>> Liming,
>> PE is UEFI spec required executable binary format. I like CLANGPDB
>> more than CLANGPE given LLVM may generate DRAWF debug symbol even
>> when generating PE.
> 
> Just a comment here to point out that while (as I stated in reply to
> Liming) my preference would be CLANGPE, I see the logic in the above,
> and would be happy with either.
> 
> (My reason for preferring CLANGPE is not exactly techincal - I just
> expect more people to know what PE is than who know what PDB is.)
> 
> Regards,
> 
> Leif
> 
>>> -----Original Message-----
>>> From: Gao, Liming <liming.gao@intel.com>
>>> Sent: Friday, November 8, 2019 9:50 AM
>>> To: devel@edk2.groups.io; leif.lindholm@linaro.org; Andrew Fish <afish@apple.com>
>>> Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>; Gao, Liming <liming.gao@intel.com>; Shi,
>>> Steven <steven.shi@intel.com>
>>> Subject: RE: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
>>> 
>>> Andrew and Leif:
>>>  Thanks for your comment. CLANG9 is different from CLANG38. And, CLANG9 will support LLVM9 or the above.
>>>  So, this tool chain should have the specific word for its purpose, and remove the version 9 to avoid the confuse.
>>> 
>>>  I prefer the tool chain name as CLANGPE or CLANGPDB. CLANGPE may be better. Now, CLANG9 tool chain
>>>  build rule family just uses CLANGPE. CLANGPE lets user know this tool chain generates PE/COFF image.
>>>  And, PE/COFF image debug symbol is PDB. So, PE also means PDB.
>>> 
>>>  Last, I just review the changes. Tool chain name update is not big. If you accept CLANGPE as tool chain name,
>>>  I will send the patch soon to catch 201911 stable tag.
>>> 
>>> Thanks
>>> Liming
>>>> -----Original Message-----
>>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Leif
>>>> Lindholm
>>>> Sent: Friday, November 08, 2019 2:37 AM
>>>> To: Andrew Fish <afish@apple.com>
>>>> Cc: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>; Ni, Ray
>>>> <ray.ni@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>
>>>> Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool
>>>> chain
>>>> 
>>>> Hi Andrew,
>>>> 
>>>> Yeah, I'm pretty easy with regards to what we change it to.
>>>> Although if we're bikeshedding, I would prefer not using _ in the
>>>> toolchain profile name.
>>>> 
>>>> I'm ... optimistic ... it won't break any of my existing scripts, but
>>>> since the build system uses it as a
>>>> <toolchain profile>_<architecture>_<build target> separator, it would
>>>> be nice if we didn't risk confusion there.
>>>> 
>>>> (I would be totally happy with PECLANG, CLANGPE, PDBCLANG, CLANGPDB or
>>>> something along those lines.)
>>>> 
>>>> Regards,
>>>> 
>>>> Leif
>>>> 
>>>> On Thu, Nov 07, 2019 at 11:54:04AM -0600, Andrew Fish wrote:
>>>>> Leif,
>>>>> 
>>>>> I think I proposed CLANG_PDB or CLANG_PECOFF. I seem to like
>>>> CLANG_PDB as assuming the PDE debugging experience is awesome/exists
>>>> on Linux and macOS is not a given.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Andrew Fish
>>>>> 
>>>>>> On Nov 7, 2019, at 11:19 AM, Leif Lindholm <leif.lindholm@linaro.org>
>>>> wrote:
>>>>>> 
>>>>>> Oops, sorry, missed this in search.
>>>>>> 
>>>>>> On Wed, Oct 30, 2019 at 03:43:44PM +0000, Liming Gao wrote:
>>>>>>> Andrew:
>>>>>>> 
>>>>>>> I prefer to keep short CLANG9 as the tool chain name. I add wiki
>>>>>>> page
>>>>>>> https://github.com/tianocore/tianocore.github.io/wiki/CLANG9-Tools-
>>>> Chain
>>>>>>> to introduce it.
>>>>>> 
>>>>>> Why should users be expected to go and read documentation in order to
>>>>>> learn that fundamental and incompatible changes to output and debug
>>>>>> format has been made as part of what looks like a simple version bump?
>>>>>> 
>>>>>>> And, we have CLANG38 tool chain. It generates ELF
>>>>>>> image and DWARF debug symbol format. It can work with LLVM 9.0
>>>>>>> release. Current tool chain tag name includes compiler name and
>>>>>>> version. There is no specific info in the tool chain name. The
>>>>>>> developer can get the more tool chain information from wiki page.
>>>>>> 
>>>>>> We aleady have the problem that people think they need to use GCC5 to
>>>>>> build EDK2 since that is the highest named GCC toolchain profile.
>>>>>> 
>>>>>> Let's not make this situation *worse* by setting up a multidimensional
>>>>>> feature matrix, based off random numerical values.
>>>>>> 
>>>>>> So say that we next have a pressing need to create a new toolchain
>>>>>> profile for clang 10, using the old ELF mechanism. Are you then
>>>>>> suggesting we set up a table on said wiki page where people have to go
>>>>>> and look up what the object and debug formats are for each CLANG##
>>>>>> toolchain profile?
>>>>>> 
>>>>>> And what if you then end up needing to do the same for the PDB
>>>>>> flavour?
>>>>>> 
>>>>>>> CLANG9 is designed to support Emulator for Windows host only.
>>>>>> 
>>>>>> Which is why it makes no sense to name it as a successor of
>>>>>> CLANG38.
>>>>>> 
>>>>>>> CLANG38 may be used for Emulator in Linux or Mac. I don’t
>>>>>>> try it before.
>>>>>>> 
>>>>>>> CLANG9 goal is to align the same compiler in the different host
>>>>>>> development environment. It can replace VS or GCC compiler. On
>>>>>>> Windows Host, I verify VS debugger for the source level debug. On
>>>>>>> Linux host, I have not verified llvm debugger. I will investigate
>>>>>>> the debugger solution for OVMF in Linux host.
>>>>>> 
>>>>>> We are not asking you to throw out this toolchain profile.
>>>>>> 
>>>>>> We are saying that since the functionality it provides is completely
>>>>>> unrelated to that of CLANG38, it should not be named in a way that
>>>>>> suggests it is merely a revision update.
>>>>>> 
>>>>>> /
>>>>>>   Leif
>>>>>> 
>>>>>>> Thanks
>>>>>>> Liming
>>>>>>> From: afish@apple.com <afish@apple.com>
>>>>>>> Sent: Saturday, October 26, 2019 2:45 AM
>>>>>>> To: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>
>>>>>>> Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L
>>>> <jordan.l.justen@intel.com>
>>>>>>> Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9
>>>> tool chain
>>>>>>> 
>>>>>>> Liming,
>>>>>>> 
>>>>>>> Sorry I missed this mail. Thanks for the info! I was doing some research
>>>> into this too and now I think I finally understand. I think the name for the tool
>>>> chain really confused me and we should think about changing the name.
>>>>>>> 
>>>>>>> From what I understand CLANG9 means produce PE/COFF directly and
>>>> used the PDB debugging format. I see from the llvm site that the linker can
>>>> produce PDB directly as you mention. This all makes sense to me now as LLVM
>>>> tries to make it easy to be a drop in replacement for VC++ or GCC. So this tool
>>>> chain is designed to be able to cross build a "Windows App" on a Linux or
>>>> macOS. It also looks like the llvm debugger, lldb, is lagging in its support for
>>>> PDB based debugging.
>>>>>>> 
>>>>>>> 
>>>>>>> Anyway I think Leif and I agree the toolchain name is very confusing. I'd
>>>> rather see it called CLANG9_WIN or CLANG_PDB.
>>>>>>> 
>>>>>>> 
>>>>>>> On Oct 18, 2019, at 7:27 AM, Liming Gao
>>>> <liming.gao@intel.com<mailto:liming.gao@intel.com>> wrote:
>>>>>>> 
>>>>>>> Andrew:
>>>>>>> Here is the cover letter on CLANG9 introduction.
>>>> https://edk2.groups.io/g/devel/message/49157
>>>>>>> 
>>>>>>> 1)      Yes. CLANG9 tool chain is added to directly generate PE/COFF image
>>>> (EFI image).
>>>>>>> This tool chain uses LLVM clang C compiler and lld linker, generates
>>>> PE/COFF
>>>>>>> image and PDB compatible debug symbol format. Now, it supports
>>>> IA32/X64 Archs.
>>>>>>> LLVM clang C compiler and lld linker are the standalone tool set. They
>>>> don’t depend other lib to generate PE/COFF image.
>>>>>>> 
>>>>>>> 2)      Yes. CLANG9 is the cross OS tool chain. It can work on
>>>> Windows/Linux/Mac host OS.
>>>>>>> LLVM LLD linker uses Windows style arguments. I verify CLANG9 for
>>>> Ovmf3264 in Windows/Linux host OS.
>>>>>>> 
>>>>>>> 
>>>>>>> On Linux can you source level debug Ovmf?
>>>>>>> 
>>>>>>> 
>>>>>>> 3)     This patch enables WinHost in Windows. It doesn’t enable UnixHost.
>>>> Now, EmulatorPkg with CLANG9 only works on Windows Host.
>>>>>>> This patch can make other modules pass build in Windows/Linux/Mac
>>>> only if LLVM9 tool set is installed.
>>>>>>> But, the generated image may not work on Linux/Mac. I agree below
>>>> linker flags are specific to windows host.
>>>>>>> So, I suggest to add the conditional statement of $(WIN_HOST_BUILD)
>>>> == TRUE for them.
>>>>>>> 
>>>>>>> 
>>>>>>> For the EmulatorPkg the Host is a native App for that OS you build on, but
>>>> it seems like CLANG9 is targeted to build Windows Apps. I'm not sure  but you
>>>> might be able to override all the linker commands to build a native app, or just
>>>> use the system linker for the Host?
>>>>>>> 
>>>>>>> I'm not sure how well debugging will work mixing PDB and DWARF
>>>> symbol formats?
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> 
>>>>>>> Andrew Fish
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> !if $(WIN_HOST_BUILD) == TRUE
>>>>>>> GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
>>>> /SUBSYSTEM:CONSOLE
>>>>>>> GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
>>>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>>>>>>> GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
>>>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>>>>>>> !endif
>>>>>>> 
>>>>>>> Thanks
>>>>>>> Liming
>>>>>>> From: afish@apple.com<mailto:afish@apple.com>
>>>> <afish@apple.com<mailto:afish@apple.com>>
>>>>>>> Sent: Friday, October 18, 2019 1:15 AM
>>>>>>> To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
>>>>>>> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>;
>>>> devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Justen, Jordan L
>>>> <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
>>>>>>> Subject: Re: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
>>>>>>> 
>>>>>>> Ray,
>>>>>>> 
>>>>>>> Sorry I'm coming a little late to this and I'm confused. I have some
>>>> questions?
>>>>>>> 1) Does CLANG9 imply CLANGPE?
>>>>>>> 2) Does CLANGPE work on Linux and macOS? Can you pass the Windows
>>>> style arguments to CLANGPE linker on Linux and macOS?
>>>>>>> 3) For the EmulatorPkg don't you have the extra requirement that
>>>> compiler needs a standard C lib (or platform specific libs) to function?
>>>>>>>      a) GCC:*_CLANG9_*_DLINK_FLAGS in EmulatorPkg.dsc seems to
>>>> imply the Linux and macOS systems will have a Windows SKD dir and a lot of
>>>> Windows DLLs? Does all that come when you install CLANG9 when you install
>>>> it on Linux or macOS?
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> So I guess I'm asking is the linker really the same for CLANG9 on all
>>>> systems? I guess the answer could be yes, but it seems the C lib for the Host
>>>> App is still an App for that OS and is OS dependent?
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Sorry if I'm missing something fundamental and this is a dumb question.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Andrew Fish
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Oct 17, 2019, at 12:27 AM, Ni, Ray
>>>> <ray.ni@intel.com<mailto:ray.ni@intel.com>> wrote:
>>>>>>> 
>>>>>>> Liming,
>>>>>>> Emulator is using a generic SEC module. The host specific module is called
>>>> "Host".
>>>>>>> So I prefer to change the macro to "WIN_HOST_BUILD", with this change,
>>>> Reviewed-by: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
>>>>>>> Sent: Thursday, October 17, 2019 2:56 PM
>>>>>>> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
>>>>>>> Cc: Justen, Jordan L
>>>> <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>; Andrew
>>>> Fish
>>>>>>> <afish@apple.com<mailto:afish@apple.com>>; Ni, Ray
>>>> <ray.ni@intel.com<mailto:ray.ni@intel.com>>
>>>>>>> Subject: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
>>>>>>> 
>>>>>>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
>>>>>>> 1. Add WIN_SEC_BUILD macro check for CLANG9 tool chain build -p
>>>>>>> EmulatorPkg\EmulatorPkg.dsc -a IA32 -DWIN_SEC_BUILD=TRUE -t
>>>> CLANG9
>>>>>>> build -p EmulatorPkg\EmulatorPkg.dsc -a X64 -DWIN_SEC_BUILD=TRUE -t
>>>>>>> CLANG9 2. Append CLANG CC and LINK flags to generate windows HOST.
>>>>>>> 3. Fix WinHost issue to call GetProcessAffinityMask() API.
>>>>>>> The input parameter should be UINTN pointer instead of UINT32 pointer.
>>>>>>> 
>>>>>>> Cc: Jordan Justen
>>>> <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
>>>>>>> Cc: Andrew Fish <afish@apple.com<mailto:afish@apple.com>>
>>>>>>> Cc: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
>>>>>>> Signed-off-by: Liming Gao
>>>> <liming.gao@intel.com<mailto:liming.gao@intel.com>>
>>>>>>> ---
>>>>>>> EmulatorPkg/Win/Host/WinHost.c   | 6 +++---
>>>>>>> EmulatorPkg/EmulatorPkg.dsc      | 7 ++++++-
>>>>>>> EmulatorPkg/Win/Host/WinHost.inf | 6 ++++++
>>>>>>> 3 files changed, 15 insertions(+), 4 deletions(-)
>>>>>>> 
>>>>>>> diff --git a/EmulatorPkg/Win/Host/WinHost.c
>>>>>>> b/EmulatorPkg/Win/Host/WinHost.c index 9aba3c8959..e40ce32548
>>>> 100644
>>>>>>> --- a/EmulatorPkg/Win/Host/WinHost.c
>>>>>>> +++ b/EmulatorPkg/Win/Host/WinHost.c
>>>>>>> @@ -356,7 +356,7 @@ Returns:
>>>>>>> INTN
>>>>>>> EFIAPI
>>>>>>> main (
>>>>>>> -  IN  INTN  Argc,
>>>>>>> +  IN  INT  Argc,
>>>>>>> IN  CHAR8 **Argv,
>>>>>>> IN  CHAR8 **Envp
>>>>>>> )
>>>>>>> @@ -391,8 +391,8 @@ Returns:
>>>>>>> VOID                  *SecFile;
>>>>>>> CHAR16                *MemorySizeStr;
>>>>>>> CHAR16                *FirmwareVolumesStr;
>>>>>>> -  UINT32                ProcessAffinityMask;
>>>>>>> -  UINT32                SystemAffinityMask;
>>>>>>> +  UINTN                 ProcessAffinityMask;
>>>>>>> +  UINTN                 SystemAffinityMask;
>>>>>>> INT32                 LowBit;
>>>>>>> 
>>>>>>> //
>>>>>>> diff --git a/EmulatorPkg/EmulatorPkg.dsc
>>>> b/EmulatorPkg/EmulatorPkg.dsc
>>>>>>> index 20f1187713..72532f5daf 100644
>>>>>>> --- a/EmulatorPkg/EmulatorPkg.dsc
>>>>>>> +++ b/EmulatorPkg/EmulatorPkg.dsc
>>>>>>> @@ -237,9 +237,10 @@
>>>>>>> 
>>>>>>> [Components]
>>>>>>> !if "IA32" in $(ARCH) || "X64" in $(ARCH)
>>>>>>> -  !if "MSFT" in $(FAMILY)
>>>>>>> +  !if "MSFT" in $(FAMILY) || $(WIN_SEC_BUILD) == TRUE
>>>>>>>   ##
>>>>>>>   #  Emulator, OS WIN application
>>>>>>> +    #  CLANG9 is cross OS tool chain. It depends on WIN_SEC_BUILD
>>>> macro.
>>>>>>>   ##
>>>>>>>   EmulatorPkg/Win/Host/WinHost.inf
>>>>>>> !else
>>>>>>> @@ -419,7 +420,11 @@
>>>>>>> 
>>>>>>> MSFT:DEBUG_*_*_CC_FLAGS = /Od /Oy-
>>>>>>> MSFT:NOOPT_*_*_CC_FLAGS = /Od /Oy-
>>>>>>> +  GCC:DEBUG_CLANG9_*_CC_FLAGS =-O0 -Wno-unused-command-
>>>> line-
>>>>>>> argument
>>>>>>> + -Wno-incompatible-pointer-types -Wno-enum-conversion
>>>>>>> + -Wno-incompatible-pointer-types -Wno-sometimes-uninitialized
>>>>>>> + -Wno-constant-conversion -Wno-main-return-type
>>>>>>> 
>>>>>>> MSFT:*_*_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
>>>>>>> /SUBSYSTEM:CONSOLE
>>>>>>> MSFT:DEBUG_*_*_DLINK_FLAGS =
>>>>>>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>>>>>>> MSFT:NOOPT_*_*_DLINK_FLAGS =
>>>>>>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>>>>>>> +  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
>>>>>>> /SUBSYSTEM:CONSOLE
>>>>>>> +  GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
>>>>>>> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>>>>>>> + GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
>>>>>>> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>>>>>>> diff --git a/EmulatorPkg/Win/Host/WinHost.inf
>>>>>>> b/EmulatorPkg/Win/Host/WinHost.inf
>>>>>>> index 631d5a6470..1adca10d79 100644
>>>>>>> --- a/EmulatorPkg/Win/Host/WinHost.inf
>>>>>>> +++ b/EmulatorPkg/Win/Host/WinHost.inf
>>>>>>> @@ -95,3 +95,9 @@
>>>>>>> MSFT:*_VS2017_X64_DLINK_FLAGS      =
>>>>>>> /LIBPATH:"%VCToolsInstallDir%lib\x64"
>>>>>>> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
>>>>>>> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
>>>>>>> /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP
>>>>>>> /OPT:REF /DEBUG /MACHINE:AMD64 /LTCG Kernel32.lib MSVCRTD.lib
>>>>>>> vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib Winmm.lib Advapi32.lib
>>>>>>> MSFT:*_*_X64_ASM_FLAGS            == /nologo /W3 /WX /c /Cx /Zd /W0
>>>> /Zi
>>>>>>> MSFT:*_*_X64_ASMLINK_FLAGS        == /link /nologo
>>>>>>> +
>>>>>>> +  GCC:*_CLANG9_X64_DLINK_FLAGS ==
>>>>>>> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
>>>>>>> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
>>>>>>> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
>>>>>>> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
>>>>>>> /LIBPATH:"%VCToolsInstallDir%lib\x64"   /NOLOGO
>>>> /SUBSYSTEM:CONSOLE
>>>>>>> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:AMD64
>>>>>>> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
>>>>>>> Winmm.lib Advapi32.lib /lldmap
>>>>>>> /EXPORT:InitializeDriver=_ModuleEntryPoint
>>>>>>> +  GCC:*_CLANG9_X64_CC_FLAGS == -m64 -g -fshort-wchar
>>>>>>> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
>>>>>>> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D
>>>> UNICODE
>>>>>>> -D
>>>>>>> + _CRT_SECURE_NO_DEPRECATE
>>>>>>> +
>>>>>>> +  GCC:*_CLANG9_IA32_DLINK_FLAGS ==
>>>>>>> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
>>>>>>> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
>>>>>>> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86"
>>>>>>> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86"
>>>>>>> /LIBPATH:"%VCToolsInstallDir%ib\x86"   /NOLOGO
>>>> /SUBSYSTEM:CONSOLE
>>>>>>> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:I386
>>>>>>> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
>>>>>>> Winmm.lib Advapi32.lib /lldmap
>>>>>>> /EXPORT:InitializeDriver=_ModuleEntryPoint
>>>>>>> +  GCC:*_CLANG9_IA32_CC_FLAGS == -m32 -g -fshort-wchar
>>>>>>> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
>>>>>>> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D
>>>> UNICODE
>>>>>>> -D
>>>>>>> + _CRT_SECURE_NO_DEPRECATE
>>>>>>> --
>>>>>>> 2.13.0.windows.1
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>> 

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

[Liming Gao]

Thanks for your feedback. I will choose CLANGPE as the tool chain name. 

Thanks
Liming
>-----Original Message-----
>From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>Andrew Fish via Groups.Io
>Sent: Tuesday, November 12, 2019 12:52 AM
>To: Leif Lindholm <leif.lindholm@linaro.org>
>Cc: Ni, Ray <ray.ni@intel.com>; Gao, Liming <liming.gao@intel.com>;
>devel@edk2.groups.io; Justen, Jordan L <jordan.l.justen@intel.com>; Shi,
>Steven <steven.shi@intel.com>
>Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool
>chain
>
>Either works for me too. I like the PDE ending a little more, but agree it is a
>little more obscure.
>> On Nov 11, 2019, at 8:39 AM, Leif Lindholm <leif.lindholm@linaro.org> wrote:
>>
>> On Fri, Nov 08, 2019 at 03:34:59AM +0000, Ni, Ray wrote:
>>> Liming,
>>> PE is UEFI spec required executable binary format. I like CLANGPDB
>>> more than CLANGPE given LLVM may generate DRAWF debug symbol
>even
>>> when generating PE.
>>
>> Just a comment here to point out that while (as I stated in reply to
>> Liming) my preference would be CLANGPE, I see the logic in the above,
>> and would be happy with either.
>>
>> (My reason for preferring CLANGPE is not exactly techincal - I just
>> expect more people to know what PE is than who know what PDB is.)
>>
>> Regards,
>>
>> Leif
>>
>>>> -----Original Message-----
>>>> From: Gao, Liming <liming.gao@intel.com>
>>>> Sent: Friday, November 8, 2019 9:50 AM
>>>> To: devel@edk2.groups.io; leif.lindholm@linaro.org; Andrew Fish
><afish@apple.com>
>>>> Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L
><jordan.l.justen@intel.com>; Gao, Liming <liming.gao@intel.com>; Shi,
>>>> Steven <steven.shi@intel.com>
>>>> Subject: RE: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9
>tool chain
>>>>
>>>> Andrew and Leif:
>>>>  Thanks for your comment. CLANG9 is different from CLANG38. And,
>CLANG9 will support LLVM9 or the above.
>>>>  So, this tool chain should have the specific word for its purpose, and
>remove the version 9 to avoid the confuse.
>>>>
>>>>  I prefer the tool chain name as CLANGPE or CLANGPDB. CLANGPE may
>be better. Now, CLANG9 tool chain
>>>>  build rule family just uses CLANGPE. CLANGPE lets user know this tool
>chain generates PE/COFF image.
>>>>  And, PE/COFF image debug symbol is PDB. So, PE also means PDB.
>>>>
>>>>  Last, I just review the changes. Tool chain name update is not big. If you
>accept CLANGPE as tool chain name,
>>>>  I will send the patch soon to catch 201911 stable tag.
>>>>
>>>> Thanks
>>>> Liming
>>>>> -----Original Message-----
>>>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf
>Of Leif
>>>>> Lindholm
>>>>> Sent: Friday, November 08, 2019 2:37 AM
>>>>> To: Andrew Fish <afish@apple.com>
>>>>> Cc: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>; Ni, Ray
>>>>> <ray.ni@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>
>>>>> Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9
>tool
>>>>> chain
>>>>>
>>>>> Hi Andrew,
>>>>>
>>>>> Yeah, I'm pretty easy with regards to what we change it to.
>>>>> Although if we're bikeshedding, I would prefer not using _ in the
>>>>> toolchain profile name.
>>>>>
>>>>> I'm ... optimistic ... it won't break any of my existing scripts, but
>>>>> since the build system uses it as a
>>>>> <toolchain profile>_<architecture>_<build target> separator, it would
>>>>> be nice if we didn't risk confusion there.
>>>>>
>>>>> (I would be totally happy with PECLANG, CLANGPE, PDBCLANG,
>CLANGPDB or
>>>>> something along those lines.)
>>>>>
>>>>> Regards,
>>>>>
>>>>> Leif
>>>>>
>>>>> On Thu, Nov 07, 2019 at 11:54:04AM -0600, Andrew Fish wrote:
>>>>>> Leif,
>>>>>>
>>>>>> I think I proposed CLANG_PDB or CLANG_PECOFF. I seem to like
>>>>> CLANG_PDB as assuming the PDE debugging experience is
>awesome/exists
>>>>> on Linux and macOS is not a given.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Andrew Fish
>>>>>>
>>>>>>> On Nov 7, 2019, at 11:19 AM, Leif Lindholm <leif.lindholm@linaro.org>
>>>>> wrote:
>>>>>>>
>>>>>>> Oops, sorry, missed this in search.
>>>>>>>
>>>>>>> On Wed, Oct 30, 2019 at 03:43:44PM +0000, Liming Gao wrote:
>>>>>>>> Andrew:
>>>>>>>>
>>>>>>>> I prefer to keep short CLANG9 as the tool chain name. I add wiki
>>>>>>>> page
>>>>>>>> https://github.com/tianocore/tianocore.github.io/wiki/CLANG9-
>Tools-
>>>>> Chain
>>>>>>>> to introduce it.
>>>>>>>
>>>>>>> Why should users be expected to go and read documentation in
>order to
>>>>>>> learn that fundamental and incompatible changes to output and
>debug
>>>>>>> format has been made as part of what looks like a simple version
>bump?
>>>>>>>
>>>>>>>> And, we have CLANG38 tool chain. It generates ELF
>>>>>>>> image and DWARF debug symbol format. It can work with LLVM 9.0
>>>>>>>> release. Current tool chain tag name includes compiler name and
>>>>>>>> version. There is no specific info in the tool chain name. The
>>>>>>>> developer can get the more tool chain information from wiki page.
>>>>>>>
>>>>>>> We aleady have the problem that people think they need to use
>GCC5 to
>>>>>>> build EDK2 since that is the highest named GCC toolchain profile.
>>>>>>>
>>>>>>> Let's not make this situation *worse* by setting up a
>multidimensional
>>>>>>> feature matrix, based off random numerical values.
>>>>>>>
>>>>>>> So say that we next have a pressing need to create a new toolchain
>>>>>>> profile for clang 10, using the old ELF mechanism. Are you then
>>>>>>> suggesting we set up a table on said wiki page where people have to
>go
>>>>>>> and look up what the object and debug formats are for each
>CLANG##
>>>>>>> toolchain profile?
>>>>>>>
>>>>>>> And what if you then end up needing to do the same for the PDB
>>>>>>> flavour?
>>>>>>>
>>>>>>>> CLANG9 is designed to support Emulator for Windows host only.
>>>>>>>
>>>>>>> Which is why it makes no sense to name it as a successor of
>>>>>>> CLANG38.
>>>>>>>
>>>>>>>> CLANG38 may be used for Emulator in Linux or Mac. I don’t
>>>>>>>> try it before.
>>>>>>>>
>>>>>>>> CLANG9 goal is to align the same compiler in the different host
>>>>>>>> development environment. It can replace VS or GCC compiler. On
>>>>>>>> Windows Host, I verify VS debugger for the source level debug. On
>>>>>>>> Linux host, I have not verified llvm debugger. I will investigate
>>>>>>>> the debugger solution for OVMF in Linux host.
>>>>>>>
>>>>>>> We are not asking you to throw out this toolchain profile.
>>>>>>>
>>>>>>> We are saying that since the functionality it provides is completely
>>>>>>> unrelated to that of CLANG38, it should not be named in a way that
>>>>>>> suggests it is merely a revision update.
>>>>>>>
>>>>>>> /
>>>>>>>   Leif
>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Liming
>>>>>>>> From: afish@apple.com <afish@apple.com>
>>>>>>>> Sent: Saturday, October 26, 2019 2:45 AM
>>>>>>>> To: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>
>>>>>>>> Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L
>>>>> <jordan.l.justen@intel.com>
>>>>>>>> Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable
>CLANG9
>>>>> tool chain
>>>>>>>>
>>>>>>>> Liming,
>>>>>>>>
>>>>>>>> Sorry I missed this mail. Thanks for the info! I was doing some
>research
>>>>> into this too and now I think I finally understand. I think the name for
>the tool
>>>>> chain really confused me and we should think about changing the name.
>>>>>>>>
>>>>>>>> From what I understand CLANG9 means produce PE/COFF directly
>and
>>>>> used the PDB debugging format. I see from the llvm site that the linker
>can
>>>>> produce PDB directly as you mention. This all makes sense to me now as
>LLVM
>>>>> tries to make it easy to be a drop in replacement for VC++ or GCC. So
>this tool
>>>>> chain is designed to be able to cross build a "Windows App" on a Linux or
>>>>> macOS. It also looks like the llvm debugger, lldb, is lagging in its support
>for
>>>>> PDB based debugging.
>>>>>>>>
>>>>>>>>
>>>>>>>> Anyway I think Leif and I agree the toolchain name is very confusing.
>I'd
>>>>> rather see it called CLANG9_WIN or CLANG_PDB.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Oct 18, 2019, at 7:27 AM, Liming Gao
>>>>> <liming.gao@intel.com<mailto:liming.gao@intel.com>> wrote:
>>>>>>>>
>>>>>>>> Andrew:
>>>>>>>> Here is the cover letter on CLANG9 introduction.
>>>>> https://edk2.groups.io/g/devel/message/49157
>>>>>>>>
>>>>>>>> 1)      Yes. CLANG9 tool chain is added to directly generate PE/COFF
>image
>>>>> (EFI image).
>>>>>>>> This tool chain uses LLVM clang C compiler and lld linker, generates
>>>>> PE/COFF
>>>>>>>> image and PDB compatible debug symbol format. Now, it supports
>>>>> IA32/X64 Archs.
>>>>>>>> LLVM clang C compiler and lld linker are the standalone tool set.
>They
>>>>> don’t depend other lib to generate PE/COFF image.
>>>>>>>>
>>>>>>>> 2)      Yes. CLANG9 is the cross OS tool chain. It can work on
>>>>> Windows/Linux/Mac host OS.
>>>>>>>> LLVM LLD linker uses Windows style arguments. I verify CLANG9 for
>>>>> Ovmf3264 in Windows/Linux host OS.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Linux can you source level debug Ovmf?
>>>>>>>>
>>>>>>>>
>>>>>>>> 3)     This patch enables WinHost in Windows. It doesn’t enable
>UnixHost.
>>>>> Now, EmulatorPkg with CLANG9 only works on Windows Host.
>>>>>>>> This patch can make other modules pass build in
>Windows/Linux/Mac
>>>>> only if LLVM9 tool set is installed.
>>>>>>>> But, the generated image may not work on Linux/Mac. I agree
>below
>>>>> linker flags are specific to windows host.
>>>>>>>> So, I suggest to add the conditional statement of
>$(WIN_HOST_BUILD)
>>>>> == TRUE for them.
>>>>>>>>
>>>>>>>>
>>>>>>>> For the EmulatorPkg the Host is a native App for that OS you build on,
>but
>>>>> it seems like CLANG9 is targeted to build Windows Apps. I'm not sure
>but you
>>>>> might be able to override all the linker commands to build a native app,
>or just
>>>>> use the system linker for the Host?
>>>>>>>>
>>>>>>>> I'm not sure how well debugging will work mixing PDB and DWARF
>>>>> symbol formats?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Andrew Fish
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> !if $(WIN_HOST_BUILD) == TRUE
>>>>>>>> GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
>>>>> /SUBSYSTEM:CONSOLE
>>>>>>>> GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
>>>>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>>>>>>>> GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
>>>>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>>>>>>>> !endif
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Liming
>>>>>>>> From: afish@apple.com<mailto:afish@apple.com>
>>>>> <afish@apple.com<mailto:afish@apple.com>>
>>>>>>>> Sent: Friday, October 18, 2019 1:15 AM
>>>>>>>> To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
>>>>>>>> Cc: Gao, Liming
><liming.gao@intel.com<mailto:liming.gao@intel.com>>;
>>>>> devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Justen, Jordan L
>>>>> <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
>>>>>>>> Subject: Re: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
>>>>>>>>
>>>>>>>> Ray,
>>>>>>>>
>>>>>>>> Sorry I'm coming a little late to this and I'm confused. I have some
>>>>> questions?
>>>>>>>> 1) Does CLANG9 imply CLANGPE?
>>>>>>>> 2) Does CLANGPE work on Linux and macOS? Can you pass the
>Windows
>>>>> style arguments to CLANGPE linker on Linux and macOS?
>>>>>>>> 3) For the EmulatorPkg don't you have the extra requirement that
>>>>> compiler needs a standard C lib (or platform specific libs) to function?
>>>>>>>>      a) GCC:*_CLANG9_*_DLINK_FLAGS in EmulatorPkg.dsc seems to
>>>>> imply the Linux and macOS systems will have a Windows SKD dir and a
>lot of
>>>>> Windows DLLs? Does all that come when you install CLANG9 when you
>install
>>>>> it on Linux or macOS?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> So I guess I'm asking is the linker really the same for CLANG9 on all
>>>>> systems? I guess the answer could be yes, but it seems the C lib for the
>Host
>>>>> App is still an App for that OS and is OS dependent?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Sorry if I'm missing something fundamental and this is a dumb
>question.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Andrew Fish
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Oct 17, 2019, at 12:27 AM, Ni, Ray
>>>>> <ray.ni@intel.com<mailto:ray.ni@intel.com>> wrote:
>>>>>>>>
>>>>>>>> Liming,
>>>>>>>> Emulator is using a generic SEC module. The host specific module is
>called
>>>>> "Host".
>>>>>>>> So I prefer to change the macro to "WIN_HOST_BUILD", with this
>change,
>>>>> Reviewed-by: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Gao, Liming
><liming.gao@intel.com<mailto:liming.gao@intel.com>>
>>>>>>>> Sent: Thursday, October 17, 2019 2:56 PM
>>>>>>>> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
>>>>>>>> Cc: Justen, Jordan L
>>>>> <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>;
>Andrew
>>>>> Fish
>>>>>>>> <afish@apple.com<mailto:afish@apple.com>>; Ni, Ray
>>>>> <ray.ni@intel.com<mailto:ray.ni@intel.com>>
>>>>>>>> Subject: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
>>>>>>>>
>>>>>>>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
>>>>>>>> 1. Add WIN_SEC_BUILD macro check for CLANG9 tool chain build -p
>>>>>>>> EmulatorPkg\EmulatorPkg.dsc -a IA32 -DWIN_SEC_BUILD=TRUE -t
>>>>> CLANG9
>>>>>>>> build -p EmulatorPkg\EmulatorPkg.dsc -a X64 -
>DWIN_SEC_BUILD=TRUE -t
>>>>>>>> CLANG9 2. Append CLANG CC and LINK flags to generate windows
>HOST.
>>>>>>>> 3. Fix WinHost issue to call GetProcessAffinityMask() API.
>>>>>>>> The input parameter should be UINTN pointer instead of UINT32
>pointer.
>>>>>>>>
>>>>>>>> Cc: Jordan Justen
>>>>> <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
>>>>>>>> Cc: Andrew Fish <afish@apple.com<mailto:afish@apple.com>>
>>>>>>>> Cc: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
>>>>>>>> Signed-off-by: Liming Gao
>>>>> <liming.gao@intel.com<mailto:liming.gao@intel.com>>
>>>>>>>> ---
>>>>>>>> EmulatorPkg/Win/Host/WinHost.c   | 6 +++---
>>>>>>>> EmulatorPkg/EmulatorPkg.dsc      | 7 ++++++-
>>>>>>>> EmulatorPkg/Win/Host/WinHost.inf | 6 ++++++
>>>>>>>> 3 files changed, 15 insertions(+), 4 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/EmulatorPkg/Win/Host/WinHost.c
>>>>>>>> b/EmulatorPkg/Win/Host/WinHost.c index 9aba3c8959..e40ce32548
>>>>> 100644
>>>>>>>> --- a/EmulatorPkg/Win/Host/WinHost.c
>>>>>>>> +++ b/EmulatorPkg/Win/Host/WinHost.c
>>>>>>>> @@ -356,7 +356,7 @@ Returns:
>>>>>>>> INTN
>>>>>>>> EFIAPI
>>>>>>>> main (
>>>>>>>> -  IN  INTN  Argc,
>>>>>>>> +  IN  INT  Argc,
>>>>>>>> IN  CHAR8 **Argv,
>>>>>>>> IN  CHAR8 **Envp
>>>>>>>> )
>>>>>>>> @@ -391,8 +391,8 @@ Returns:
>>>>>>>> VOID                  *SecFile;
>>>>>>>> CHAR16                *MemorySizeStr;
>>>>>>>> CHAR16                *FirmwareVolumesStr;
>>>>>>>> -  UINT32                ProcessAffinityMask;
>>>>>>>> -  UINT32                SystemAffinityMask;
>>>>>>>> +  UINTN                 ProcessAffinityMask;
>>>>>>>> +  UINTN                 SystemAffinityMask;
>>>>>>>> INT32                 LowBit;
>>>>>>>>
>>>>>>>> //
>>>>>>>> diff --git a/EmulatorPkg/EmulatorPkg.dsc
>>>>> b/EmulatorPkg/EmulatorPkg.dsc
>>>>>>>> index 20f1187713..72532f5daf 100644
>>>>>>>> --- a/EmulatorPkg/EmulatorPkg.dsc
>>>>>>>> +++ b/EmulatorPkg/EmulatorPkg.dsc
>>>>>>>> @@ -237,9 +237,10 @@
>>>>>>>>
>>>>>>>> [Components]
>>>>>>>> !if "IA32" in $(ARCH) || "X64" in $(ARCH)
>>>>>>>> -  !if "MSFT" in $(FAMILY)
>>>>>>>> +  !if "MSFT" in $(FAMILY) || $(WIN_SEC_BUILD) == TRUE
>>>>>>>>   ##
>>>>>>>>   #  Emulator, OS WIN application
>>>>>>>> +    #  CLANG9 is cross OS tool chain. It depends on WIN_SEC_BUILD
>>>>> macro.
>>>>>>>>   ##
>>>>>>>>   EmulatorPkg/Win/Host/WinHost.inf
>>>>>>>> !else
>>>>>>>> @@ -419,7 +420,11 @@
>>>>>>>>
>>>>>>>> MSFT:DEBUG_*_*_CC_FLAGS = /Od /Oy-
>>>>>>>> MSFT:NOOPT_*_*_CC_FLAGS = /Od /Oy-
>>>>>>>> +  GCC:DEBUG_CLANG9_*_CC_FLAGS =-O0 -Wno-unused-
>command-
>>>>> line-
>>>>>>>> argument
>>>>>>>> + -Wno-incompatible-pointer-types -Wno-enum-conversion
>>>>>>>> + -Wno-incompatible-pointer-types -Wno-sometimes-uninitialized
>>>>>>>> + -Wno-constant-conversion -Wno-main-return-type
>>>>>>>>
>>>>>>>> MSFT:*_*_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
>>>>>>>> /SUBSYSTEM:CONSOLE
>>>>>>>> MSFT:DEBUG_*_*_DLINK_FLAGS =
>>>>>>>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>>>>>>>> MSFT:NOOPT_*_*_DLINK_FLAGS =
>>>>>>>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>>>>>>>> +  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096
>/FILEALIGN:4096
>>>>>>>> /SUBSYSTEM:CONSOLE
>>>>>>>> +  GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
>>>>>>>> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>>>>>>>> + GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
>>>>>>>> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
>>>>>>>> diff --git a/EmulatorPkg/Win/Host/WinHost.inf
>>>>>>>> b/EmulatorPkg/Win/Host/WinHost.inf
>>>>>>>> index 631d5a6470..1adca10d79 100644
>>>>>>>> --- a/EmulatorPkg/Win/Host/WinHost.inf
>>>>>>>> +++ b/EmulatorPkg/Win/Host/WinHost.inf
>>>>>>>> @@ -95,3 +95,9 @@
>>>>>>>> MSFT:*_VS2017_X64_DLINK_FLAGS      =
>>>>>>>> /LIBPATH:"%VCToolsInstallDir%lib\x64"
>>>>>>>> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
>>>>>>>>
>/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
>>>>>>>> /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086
>/MAP
>>>>>>>> /OPT:REF /DEBUG /MACHINE:AMD64 /LTCG Kernel32.lib
>MSVCRTD.lib
>>>>>>>> vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib Winmm.lib Advapi32.lib
>>>>>>>> MSFT:*_*_X64_ASM_FLAGS            == /nologo /W3 /WX /c /Cx /Zd
>/W0
>>>>> /Zi
>>>>>>>> MSFT:*_*_X64_ASMLINK_FLAGS        == /link /nologo
>>>>>>>> +
>>>>>>>> +  GCC:*_CLANG9_X64_DLINK_FLAGS ==
>>>>>>>> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
>>>>>>>> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
>>>>>>>> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
>>>>>>>>
>/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
>>>>>>>> /LIBPATH:"%VCToolsInstallDir%lib\x64"   /NOLOGO
>>>>> /SUBSYSTEM:CONSOLE
>>>>>>>> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG
>/MACHINE:AMD64
>>>>>>>> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib
>User32.lib
>>>>>>>> Winmm.lib Advapi32.lib /lldmap
>>>>>>>> /EXPORT:InitializeDriver=_ModuleEntryPoint
>>>>>>>> +  GCC:*_CLANG9_X64_CC_FLAGS == -m64 -g -fshort-wchar
>>>>>>>> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
>>>>>>>> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D
>>>>> UNICODE
>>>>>>>> -D
>>>>>>>> + _CRT_SECURE_NO_DEPRECATE
>>>>>>>> +
>>>>>>>> +  GCC:*_CLANG9_IA32_DLINK_FLAGS ==
>>>>>>>> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
>>>>>>>> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
>>>>>>>> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86"
>>>>>>>>
>/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86"
>>>>>>>> /LIBPATH:"%VCToolsInstallDir%ib\x86"   /NOLOGO
>>>>> /SUBSYSTEM:CONSOLE
>>>>>>>> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:I386
>>>>>>>> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib
>User32.lib
>>>>>>>> Winmm.lib Advapi32.lib /lldmap
>>>>>>>> /EXPORT:InitializeDriver=_ModuleEntryPoint
>>>>>>>> +  GCC:*_CLANG9_IA32_CC_FLAGS == -m32 -g -fshort-wchar
>>>>>>>> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
>>>>>>>> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D
>>>>> UNICODE
>>>>>>>> -D
>>>>>>>> + _CRT_SECURE_NO_DEPRECATE
>>>>>>>> --
>>>>>>>> 2.13.0.windows.1
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>
>

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

[Ni, Ray]

Liming,
What name will be chosen when in future someone wants a LLVM toolchain which
supports DWARF debug symbol?


> -----Original Message-----
> From: Gao, Liming <liming.gao@intel.com>
> Sent: Tuesday, November 12, 2019 8:41 AM
> To: devel@edk2.groups.io; afish@apple.com; Leif Lindholm
> <leif.lindholm@linaro.org>
> Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>;
> Shi, Steven <steven.shi@intel.com>; Gao, Liming <liming.gao@intel.com>
> Subject: RE: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool
> chain
> 
> Thanks for your feedback. I will choose CLANGPE as the tool chain name.
> 
> Thanks
> Liming
> >-----Original Message-----
> >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> >Andrew Fish via Groups.Io
> >Sent: Tuesday, November 12, 2019 12:52 AM
> >To: Leif Lindholm <leif.lindholm@linaro.org>
> >Cc: Ni, Ray <ray.ni@intel.com>; Gao, Liming <liming.gao@intel.com>;
> >devel@edk2.groups.io; Justen, Jordan L <jordan.l.justen@intel.com>;
> >Shi, Steven <steven.shi@intel.com>
> >Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9
> >tool chain
> >
> >Either works for me too. I like the PDE ending a little more, but agree
> >it is a little more obscure.
> >> On Nov 11, 2019, at 8:39 AM, Leif Lindholm <leif.lindholm@linaro.org>
> wrote:
> >>
> >> On Fri, Nov 08, 2019 at 03:34:59AM +0000, Ni, Ray wrote:
> >>> Liming,
> >>> PE is UEFI spec required executable binary format. I like CLANGPDB
> >>> more than CLANGPE given LLVM may generate DRAWF debug symbol
> >even
> >>> when generating PE.
> >>
> >> Just a comment here to point out that while (as I stated in reply to
> >> Liming) my preference would be CLANGPE, I see the logic in the above,
> >> and would be happy with either.
> >>
> >> (My reason for preferring CLANGPE is not exactly techincal - I just
> >> expect more people to know what PE is than who know what PDB is.)
> >>
> >> Regards,
> >>
> >> Leif
> >>
> >>>> -----Original Message-----
> >>>> From: Gao, Liming <liming.gao@intel.com>
> >>>> Sent: Friday, November 8, 2019 9:50 AM
> >>>> To: devel@edk2.groups.io; leif.lindholm@linaro.org; Andrew Fish
> ><afish@apple.com>
> >>>> Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L
> ><jordan.l.justen@intel.com>; Gao, Liming <liming.gao@intel.com>; Shi,
> >>>> Steven <steven.shi@intel.com>
> >>>> Subject: RE: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable
> >>>> CLANG9
> >tool chain
> >>>>
> >>>> Andrew and Leif:
> >>>>  Thanks for your comment. CLANG9 is different from CLANG38. And,
> >CLANG9 will support LLVM9 or the above.
> >>>>  So, this tool chain should have the specific word for its purpose,
> >>>> and
> >remove the version 9 to avoid the confuse.
> >>>>
> >>>>  I prefer the tool chain name as CLANGPE or CLANGPDB. CLANGPE may
> >be better. Now, CLANG9 tool chain
> >>>>  build rule family just uses CLANGPE. CLANGPE lets user know this
> >>>> tool
> >chain generates PE/COFF image.
> >>>>  And, PE/COFF image debug symbol is PDB. So, PE also means PDB.
> >>>>
> >>>>  Last, I just review the changes. Tool chain name update is not
> >>>> big. If you
> >accept CLANGPE as tool chain name,
> >>>>  I will send the patch soon to catch 201911 stable tag.
> >>>>
> >>>> Thanks
> >>>> Liming
> >>>>> -----Original Message-----
> >>>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On
> Behalf
> >Of Leif
> >>>>> Lindholm
> >>>>> Sent: Friday, November 08, 2019 2:37 AM
> >>>>> To: Andrew Fish <afish@apple.com>
> >>>>> Cc: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>; Ni,
> >>>>> Ray <ray.ni@intel.com>; Justen, Jordan L
> >>>>> <jordan.l.justen@intel.com>
> >>>>> Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable
> >>>>> CLANG9
> >tool
> >>>>> chain
> >>>>>
> >>>>> Hi Andrew,
> >>>>>
> >>>>> Yeah, I'm pretty easy with regards to what we change it to.
> >>>>> Although if we're bikeshedding, I would prefer not using _ in the
> >>>>> toolchain profile name.
> >>>>>
> >>>>> I'm ... optimistic ... it won't break any of my existing scripts,
> >>>>> but since the build system uses it as a <toolchain
> >>>>> profile>_<architecture>_<build target> separator, it would be nice
> >>>>> if we didn't risk confusion there.
> >>>>>
> >>>>> (I would be totally happy with PECLANG, CLANGPE, PDBCLANG,
> >CLANGPDB or
> >>>>> something along those lines.)
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Leif
> >>>>>
> >>>>> On Thu, Nov 07, 2019 at 11:54:04AM -0600, Andrew Fish wrote:
> >>>>>> Leif,
> >>>>>>
> >>>>>> I think I proposed CLANG_PDB or CLANG_PECOFF. I seem to like
> >>>>> CLANG_PDB as assuming the PDE debugging experience is
> >awesome/exists
> >>>>> on Linux and macOS is not a given.
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> Andrew Fish
> >>>>>>
> >>>>>>> On Nov 7, 2019, at 11:19 AM, Leif Lindholm
> >>>>>>> <leif.lindholm@linaro.org>
> >>>>> wrote:
> >>>>>>>
> >>>>>>> Oops, sorry, missed this in search.
> >>>>>>>
> >>>>>>> On Wed, Oct 30, 2019 at 03:43:44PM +0000, Liming Gao wrote:
> >>>>>>>> Andrew:
> >>>>>>>>
> >>>>>>>> I prefer to keep short CLANG9 as the tool chain name. I add
> >>>>>>>> wiki page
> >>>>>>>> https://github.com/tianocore/tianocore.github.io/wiki/CLANG9-
> >Tools-
> >>>>> Chain
> >>>>>>>> to introduce it.
> >>>>>>>
> >>>>>>> Why should users be expected to go and read documentation in
> >order to
> >>>>>>> learn that fundamental and incompatible changes to output and
> >debug
> >>>>>>> format has been made as part of what looks like a simple version
> >bump?
> >>>>>>>
> >>>>>>>> And, we have CLANG38 tool chain. It generates ELF image and
> >>>>>>>> DWARF debug symbol format. It can work with LLVM 9.0 release.
> >>>>>>>> Current tool chain tag name includes compiler name and version.
> >>>>>>>> There is no specific info in the tool chain name. The developer
> >>>>>>>> can get the more tool chain information from wiki page.
> >>>>>>>
> >>>>>>> We aleady have the problem that people think they need to use
> >GCC5 to
> >>>>>>> build EDK2 since that is the highest named GCC toolchain profile.
> >>>>>>>
> >>>>>>> Let's not make this situation *worse* by setting up a
> >multidimensional
> >>>>>>> feature matrix, based off random numerical values.
> >>>>>>>
> >>>>>>> So say that we next have a pressing need to create a new
> >>>>>>> toolchain profile for clang 10, using the old ELF mechanism. Are
> >>>>>>> you then suggesting we set up a table on said wiki page where
> >>>>>>> people have to
> >go
> >>>>>>> and look up what the object and debug formats are for each
> >CLANG##
> >>>>>>> toolchain profile?
> >>>>>>>
> >>>>>>> And what if you then end up needing to do the same for the PDB
> >>>>>>> flavour?
> >>>>>>>
> >>>>>>>> CLANG9 is designed to support Emulator for Windows host only.
> >>>>>>>
> >>>>>>> Which is why it makes no sense to name it as a successor of
> >>>>>>> CLANG38.
> >>>>>>>
> >>>>>>>> CLANG38 may be used for Emulator in Linux or Mac. I don’t try
> >>>>>>>> it before.
> >>>>>>>>
> >>>>>>>> CLANG9 goal is to align the same compiler in the different host
> >>>>>>>> development environment. It can replace VS or GCC compiler. On
> >>>>>>>> Windows Host, I verify VS debugger for the source level debug.
> >>>>>>>> On Linux host, I have not verified llvm debugger. I will
> >>>>>>>> investigate the debugger solution for OVMF in Linux host.
> >>>>>>>
> >>>>>>> We are not asking you to throw out this toolchain profile.
> >>>>>>>
> >>>>>>> We are saying that since the functionality it provides is
> >>>>>>> completely unrelated to that of CLANG38, it should not be named
> >>>>>>> in a way that suggests it is merely a revision update.
> >>>>>>>
> >>>>>>> /
> >>>>>>>   Leif
> >>>>>>>
> >>>>>>>> Thanks
> >>>>>>>> Liming
> >>>>>>>> From: afish@apple.com <afish@apple.com>
> >>>>>>>> Sent: Saturday, October 26, 2019 2:45 AM
> >>>>>>>> To: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>
> >>>>>>>> Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L
> >>>>> <jordan.l.justen@intel.com>
> >>>>>>>> Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable
> >CLANG9
> >>>>> tool chain
> >>>>>>>>
> >>>>>>>> Liming,
> >>>>>>>>
> >>>>>>>> Sorry I missed this mail. Thanks for the info! I was doing some
> >research
> >>>>> into this too and now I think I finally understand. I think the
> >>>>> name for
> >the tool
> >>>>> chain really confused me and we should think about changing the
> name.
> >>>>>>>>
> >>>>>>>> From what I understand CLANG9 means produce PE/COFF directly
> >and
> >>>>> used the PDB debugging format. I see from the llvm site that the
> >>>>> linker
> >can
> >>>>> produce PDB directly as you mention. This all makes sense to me
> >>>>> now as
> >LLVM
> >>>>> tries to make it easy to be a drop in replacement for VC++ or GCC.
> >>>>> So
> >this tool
> >>>>> chain is designed to be able to cross build a "Windows App" on a
> >>>>> Linux or macOS. It also looks like the llvm debugger, lldb, is
> >>>>> lagging in its support
> >for
> >>>>> PDB based debugging.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Anyway I think Leif and I agree the toolchain name is very
> confusing.
> >I'd
> >>>>> rather see it called CLANG9_WIN or CLANG_PDB.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Oct 18, 2019, at 7:27 AM, Liming Gao
> >>>>> <liming.gao@intel.com<mailto:liming.gao@intel.com>> wrote:
> >>>>>>>>
> >>>>>>>> Andrew:
> >>>>>>>> Here is the cover letter on CLANG9 introduction.
> >>>>> https://edk2.groups.io/g/devel/message/49157
> >>>>>>>>
> >>>>>>>> 1)      Yes. CLANG9 tool chain is added to directly generate PE/COFF
> >image
> >>>>> (EFI image).
> >>>>>>>> This tool chain uses LLVM clang C compiler and lld linker,
> >>>>>>>> generates
> >>>>> PE/COFF
> >>>>>>>> image and PDB compatible debug symbol format. Now, it
> supports
> >>>>> IA32/X64 Archs.
> >>>>>>>> LLVM clang C compiler and lld linker are the standalone tool set.
> >They
> >>>>> don’t depend other lib to generate PE/COFF image.
> >>>>>>>>
> >>>>>>>> 2)      Yes. CLANG9 is the cross OS tool chain. It can work on
> >>>>> Windows/Linux/Mac host OS.
> >>>>>>>> LLVM LLD linker uses Windows style arguments. I verify CLANG9
> >>>>>>>> for
> >>>>> Ovmf3264 in Windows/Linux host OS.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Linux can you source level debug Ovmf?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 3)     This patch enables WinHost in Windows. It doesn’t enable
> >UnixHost.
> >>>>> Now, EmulatorPkg with CLANG9 only works on Windows Host.
> >>>>>>>> This patch can make other modules pass build in
> >Windows/Linux/Mac
> >>>>> only if LLVM9 tool set is installed.
> >>>>>>>> But, the generated image may not work on Linux/Mac. I agree
> >below
> >>>>> linker flags are specific to windows host.
> >>>>>>>> So, I suggest to add the conditional statement of
> >$(WIN_HOST_BUILD)
> >>>>> == TRUE for them.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> For the EmulatorPkg the Host is a native App for that OS you
> >>>>>>>> build on,
> >but
> >>>>> it seems like CLANG9 is targeted to build Windows Apps. I'm not
> >>>>> sure
> >but you
> >>>>> might be able to override all the linker commands to build a
> >>>>> native app,
> >or just
> >>>>> use the system linker for the Host?
> >>>>>>>>
> >>>>>>>> I'm not sure how well debugging will work mixing PDB and DWARF
> >>>>> symbol formats?
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>> Andrew Fish
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> !if $(WIN_HOST_BUILD) == TRUE
> >>>>>>>> GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096
> /FILEALIGN:4096
> >>>>> /SUBSYSTEM:CONSOLE
> >>>>>>>> GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
> >>>>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> >>>>>>>> GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
> >>>>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> >>>>>>>> !endif
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>>> Liming
> >>>>>>>> From: afish@apple.com<mailto:afish@apple.com>
> >>>>> <afish@apple.com<mailto:afish@apple.com>>
> >>>>>>>> Sent: Friday, October 18, 2019 1:15 AM
> >>>>>>>> To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> >>>>>>>> Cc: Gao, Liming
> ><liming.gao@intel.com<mailto:liming.gao@intel.com>>;
> >>>>> devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Justen,
> Jordan
> >>>>> L <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
> >>>>>>>> Subject: Re: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool
> >>>>>>>> chain
> >>>>>>>>
> >>>>>>>> Ray,
> >>>>>>>>
> >>>>>>>> Sorry I'm coming a little late to this and I'm confused. I have
> >>>>>>>> some
> >>>>> questions?
> >>>>>>>> 1) Does CLANG9 imply CLANGPE?
> >>>>>>>> 2) Does CLANGPE work on Linux and macOS? Can you pass the
> >Windows
> >>>>> style arguments to CLANGPE linker on Linux and macOS?
> >>>>>>>> 3) For the EmulatorPkg don't you have the extra requirement
> >>>>>>>> that
> >>>>> compiler needs a standard C lib (or platform specific libs) to function?
> >>>>>>>>      a) GCC:*_CLANG9_*_DLINK_FLAGS in EmulatorPkg.dsc seems
> to
> >>>>> imply the Linux and macOS systems will have a Windows SKD dir and
> >>>>> a
> >lot of
> >>>>> Windows DLLs? Does all that come when you install CLANG9 when
> you
> >install
> >>>>> it on Linux or macOS?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> So I guess I'm asking is the linker really the same for CLANG9
> >>>>>>>> on all
> >>>>> systems? I guess the answer could be yes, but it seems the C lib
> >>>>> for the
> >Host
> >>>>> App is still an App for that OS and is OS dependent?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Sorry if I'm missing something fundamental and this is a dumb
> >question.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Andrew Fish
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Oct 17, 2019, at 12:27 AM, Ni, Ray
> >>>>> <ray.ni@intel.com<mailto:ray.ni@intel.com>> wrote:
> >>>>>>>>
> >>>>>>>> Liming,
> >>>>>>>> Emulator is using a generic SEC module. The host specific
> >>>>>>>> module is
> >called
> >>>>> "Host".
> >>>>>>>> So I prefer to change the macro to "WIN_HOST_BUILD", with this
> >change,
> >>>>> Reviewed-by: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Gao, Liming
> ><liming.gao@intel.com<mailto:liming.gao@intel.com>>
> >>>>>>>> Sent: Thursday, October 17, 2019 2:56 PM
> >>>>>>>> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> >>>>>>>> Cc: Justen, Jordan L
> >>>>> <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>;
> >Andrew
> >>>>> Fish
> >>>>>>>> <afish@apple.com<mailto:afish@apple.com>>; Ni, Ray
> >>>>> <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> >>>>>>>> Subject: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
> >>>>>>>>
> >>>>>>>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
> >>>>>>>> 1. Add WIN_SEC_BUILD macro check for CLANG9 tool chain build -
> p
> >>>>>>>> EmulatorPkg\EmulatorPkg.dsc -a IA32 -DWIN_SEC_BUILD=TRUE -t
> >>>>> CLANG9
> >>>>>>>> build -p EmulatorPkg\EmulatorPkg.dsc -a X64 -
> >DWIN_SEC_BUILD=TRUE -t
> >>>>>>>> CLANG9 2. Append CLANG CC and LINK flags to generate windows
> >HOST.
> >>>>>>>> 3. Fix WinHost issue to call GetProcessAffinityMask() API.
> >>>>>>>> The input parameter should be UINTN pointer instead of UINT32
> >pointer.
> >>>>>>>>
> >>>>>>>> Cc: Jordan Justen
> >>>>> <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
> >>>>>>>> Cc: Andrew Fish <afish@apple.com<mailto:afish@apple.com>>
> >>>>>>>> Cc: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> >>>>>>>> Signed-off-by: Liming Gao
> >>>>> <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> >>>>>>>> ---
> >>>>>>>> EmulatorPkg/Win/Host/WinHost.c   | 6 +++---
> >>>>>>>> EmulatorPkg/EmulatorPkg.dsc      | 7 ++++++-
> >>>>>>>> EmulatorPkg/Win/Host/WinHost.inf | 6 ++++++
> >>>>>>>> 3 files changed, 15 insertions(+), 4 deletions(-)
> >>>>>>>>
> >>>>>>>> diff --git a/EmulatorPkg/Win/Host/WinHost.c
> >>>>>>>> b/EmulatorPkg/Win/Host/WinHost.c index
> 9aba3c8959..e40ce32548
> >>>>> 100644
> >>>>>>>> --- a/EmulatorPkg/Win/Host/WinHost.c
> >>>>>>>> +++ b/EmulatorPkg/Win/Host/WinHost.c
> >>>>>>>> @@ -356,7 +356,7 @@ Returns:
> >>>>>>>> INTN
> >>>>>>>> EFIAPI
> >>>>>>>> main (
> >>>>>>>> -  IN  INTN  Argc,
> >>>>>>>> +  IN  INT  Argc,
> >>>>>>>> IN  CHAR8 **Argv,
> >>>>>>>> IN  CHAR8 **Envp
> >>>>>>>> )
> >>>>>>>> @@ -391,8 +391,8 @@ Returns:
> >>>>>>>> VOID                  *SecFile;
> >>>>>>>> CHAR16                *MemorySizeStr;
> >>>>>>>> CHAR16                *FirmwareVolumesStr;
> >>>>>>>> -  UINT32                ProcessAffinityMask;
> >>>>>>>> -  UINT32                SystemAffinityMask;
> >>>>>>>> +  UINTN                 ProcessAffinityMask;
> >>>>>>>> +  UINTN                 SystemAffinityMask;
> >>>>>>>> INT32                 LowBit;
> >>>>>>>>
> >>>>>>>> //
> >>>>>>>> diff --git a/EmulatorPkg/EmulatorPkg.dsc
> >>>>> b/EmulatorPkg/EmulatorPkg.dsc
> >>>>>>>> index 20f1187713..72532f5daf 100644
> >>>>>>>> --- a/EmulatorPkg/EmulatorPkg.dsc
> >>>>>>>> +++ b/EmulatorPkg/EmulatorPkg.dsc
> >>>>>>>> @@ -237,9 +237,10 @@
> >>>>>>>>
> >>>>>>>> [Components]
> >>>>>>>> !if "IA32" in $(ARCH) || "X64" in $(ARCH)
> >>>>>>>> -  !if "MSFT" in $(FAMILY)
> >>>>>>>> +  !if "MSFT" in $(FAMILY) || $(WIN_SEC_BUILD) == TRUE
> >>>>>>>>   ##
> >>>>>>>>   #  Emulator, OS WIN application
> >>>>>>>> +    #  CLANG9 is cross OS tool chain. It depends on
> >>>>>>>> + WIN_SEC_BUILD
> >>>>> macro.
> >>>>>>>>   ##
> >>>>>>>>   EmulatorPkg/Win/Host/WinHost.inf !else @@ -419,7 +420,11
> @@
> >>>>>>>>
> >>>>>>>> MSFT:DEBUG_*_*_CC_FLAGS = /Od /Oy-
> MSFT:NOOPT_*_*_CC_FLAGS =
> >>>>>>>> /Od /Oy-
> >>>>>>>> +  GCC:DEBUG_CLANG9_*_CC_FLAGS =-O0 -Wno-unused-
> >command-
> >>>>> line-
> >>>>>>>> argument
> >>>>>>>> + -Wno-incompatible-pointer-types -Wno-enum-conversion
> >>>>>>>> + -Wno-incompatible-pointer-types -Wno-sometimes-
> uninitialized
> >>>>>>>> + -Wno-constant-conversion -Wno-main-return-type
> >>>>>>>>
> >>>>>>>> MSFT:*_*_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
> >>>>>>>> /SUBSYSTEM:CONSOLE
> >>>>>>>> MSFT:DEBUG_*_*_DLINK_FLAGS =
> >>>>>>>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> >>>>>>>> MSFT:NOOPT_*_*_DLINK_FLAGS =
> >>>>>>>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> >>>>>>>> +  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096
> >/FILEALIGN:4096
> >>>>>>>> /SUBSYSTEM:CONSOLE
> >>>>>>>> +  GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
> >>>>>>>> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> /BASE:0x10000
> >>>>>>>> + GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
> >>>>>>>> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> /BASE:0x10000
> >>>>>>>> diff --git a/EmulatorPkg/Win/Host/WinHost.inf
> >>>>>>>> b/EmulatorPkg/Win/Host/WinHost.inf
> >>>>>>>> index 631d5a6470..1adca10d79 100644
> >>>>>>>> --- a/EmulatorPkg/Win/Host/WinHost.inf
> >>>>>>>> +++ b/EmulatorPkg/Win/Host/WinHost.inf
> >>>>>>>> @@ -95,3 +95,9 @@
> >>>>>>>> MSFT:*_VS2017_X64_DLINK_FLAGS      =
> >>>>>>>> /LIBPATH:"%VCToolsInstallDir%lib\x64"
> >>>>>>>> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
> >>>>>>>>
> >/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
> >>>>>>>> /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086
> >/MAP
> >>>>>>>> /OPT:REF /DEBUG /MACHINE:AMD64 /LTCG Kernel32.lib
> >MSVCRTD.lib
> >>>>>>>> vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib Winmm.lib
> Advapi32.lib
> >>>>>>>> MSFT:*_*_X64_ASM_FLAGS            == /nologo /W3 /WX /c /Cx /Zd
> >/W0
> >>>>> /Zi
> >>>>>>>> MSFT:*_*_X64_ASMLINK_FLAGS        == /link /nologo
> >>>>>>>> +
> >>>>>>>> +  GCC:*_CLANG9_X64_DLINK_FLAGS ==
> >>>>>>>> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
> >>>>>>>> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> >>>>>>>> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
> >>>>>>>>
> >/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
> >>>>>>>> /LIBPATH:"%VCToolsInstallDir%lib\x64"   /NOLOGO
> >>>>> /SUBSYSTEM:CONSOLE
> >>>>>>>> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG
> >/MACHINE:AMD64
> >>>>>>>> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib
> >User32.lib
> >>>>>>>> Winmm.lib Advapi32.lib /lldmap
> >>>>>>>> /EXPORT:InitializeDriver=_ModuleEntryPoint
> >>>>>>>> +  GCC:*_CLANG9_X64_CC_FLAGS == -m64 -g -fshort-wchar
> >>>>>>>> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
> >>>>>>>> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D
> >>>>> UNICODE
> >>>>>>>> -D
> >>>>>>>> + _CRT_SECURE_NO_DEPRECATE
> >>>>>>>> +
> >>>>>>>> +  GCC:*_CLANG9_IA32_DLINK_FLAGS ==
> >>>>>>>> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
> >>>>>>>> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> >>>>>>>> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86"
> >>>>>>>>
> >/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86"
> >>>>>>>> /LIBPATH:"%VCToolsInstallDir%ib\x86"   /NOLOGO
> >>>>> /SUBSYSTEM:CONSOLE
> >>>>>>>> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:I386
> >>>>>>>> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib
> >User32.lib
> >>>>>>>> Winmm.lib Advapi32.lib /lldmap
> >>>>>>>> /EXPORT:InitializeDriver=_ModuleEntryPoint
> >>>>>>>> +  GCC:*_CLANG9_IA32_CC_FLAGS == -m32 -g -fshort-wchar
> >>>>>>>> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
> >>>>>>>> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D
> >>>>> UNICODE
> >>>>>>>> -D
> >>>>>>>> + _CRT_SECURE_NO_DEPRECATE
> >>>>>>>> --
> >>>>>>>> 2.13.0.windows.1
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>
> >
> >

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

[Ni, Ray]

My point is if we choose CLANGPE, for LLVM toolchain supporting DWARF debug symbol,
there is no proper name left: we cannot use CLANGELF.

Andrew, you said CLANGPDE. A typo?

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Ni, Ray
> Sent: Tuesday, November 12, 2019 9:46 AM
> To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io;
> afish@apple.com; Leif Lindholm <leif.lindholm@linaro.org>
> Cc: Justen, Jordan L <jordan.l.justen@intel.com>; Shi, Steven
> <steven.shi@intel.com>
> Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool
> chain
> 
> Liming,
> What name will be chosen when in future someone wants a LLVM toolchain
> which supports DWARF debug symbol?
> 
> 
> > -----Original Message-----
> > From: Gao, Liming <liming.gao@intel.com>
> > Sent: Tuesday, November 12, 2019 8:41 AM
> > To: devel@edk2.groups.io; afish@apple.com; Leif Lindholm
> > <leif.lindholm@linaro.org>
> > Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L
> > <jordan.l.justen@intel.com>; Shi, Steven <steven.shi@intel.com>; Gao,
> > Liming <liming.gao@intel.com>
> > Subject: RE: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9
> > tool chain
> >
> > Thanks for your feedback. I will choose CLANGPE as the tool chain name.
> >
> > Thanks
> > Liming
> > >-----Original Message-----
> > >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> > >Andrew Fish via Groups.Io
> > >Sent: Tuesday, November 12, 2019 12:52 AM
> > >To: Leif Lindholm <leif.lindholm@linaro.org>
> > >Cc: Ni, Ray <ray.ni@intel.com>; Gao, Liming <liming.gao@intel.com>;
> > >devel@edk2.groups.io; Justen, Jordan L <jordan.l.justen@intel.com>;
> > >Shi, Steven <steven.shi@intel.com>
> > >Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9
> > >tool chain
> > >
> > >Either works for me too. I like the PDE ending a little more, but
> > >agree it is a little more obscure.
> > >> On Nov 11, 2019, at 8:39 AM, Leif Lindholm
> > >> <leif.lindholm@linaro.org>
> > wrote:
> > >>
> > >> On Fri, Nov 08, 2019 at 03:34:59AM +0000, Ni, Ray wrote:
> > >>> Liming,
> > >>> PE is UEFI spec required executable binary format. I like CLANGPDB
> > >>> more than CLANGPE given LLVM may generate DRAWF debug symbol
> > >even
> > >>> when generating PE.
> > >>
> > >> Just a comment here to point out that while (as I stated in reply
> > >> to
> > >> Liming) my preference would be CLANGPE, I see the logic in the
> > >> above, and would be happy with either.
> > >>
> > >> (My reason for preferring CLANGPE is not exactly techincal - I just
> > >> expect more people to know what PE is than who know what PDB is.)
> > >>
> > >> Regards,
> > >>
> > >> Leif
> > >>
> > >>>> -----Original Message-----
> > >>>> From: Gao, Liming <liming.gao@intel.com>
> > >>>> Sent: Friday, November 8, 2019 9:50 AM
> > >>>> To: devel@edk2.groups.io; leif.lindholm@linaro.org; Andrew Fish
> > ><afish@apple.com>
> > >>>> Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L
> > ><jordan.l.justen@intel.com>; Gao, Liming <liming.gao@intel.com>; Shi,
> > >>>> Steven <steven.shi@intel.com>
> > >>>> Subject: RE: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable
> > >>>> CLANG9
> > >tool chain
> > >>>>
> > >>>> Andrew and Leif:
> > >>>>  Thanks for your comment. CLANG9 is different from CLANG38. And,
> > >CLANG9 will support LLVM9 or the above.
> > >>>>  So, this tool chain should have the specific word for its
> > >>>> purpose, and
> > >remove the version 9 to avoid the confuse.
> > >>>>
> > >>>>  I prefer the tool chain name as CLANGPE or CLANGPDB. CLANGPE
> may
> > >be better. Now, CLANG9 tool chain
> > >>>>  build rule family just uses CLANGPE. CLANGPE lets user know this
> > >>>> tool
> > >chain generates PE/COFF image.
> > >>>>  And, PE/COFF image debug symbol is PDB. So, PE also means PDB.
> > >>>>
> > >>>>  Last, I just review the changes. Tool chain name update is not
> > >>>> big. If you
> > >accept CLANGPE as tool chain name,
> > >>>>  I will send the patch soon to catch 201911 stable tag.
> > >>>>
> > >>>> Thanks
> > >>>> Liming
> > >>>>> -----Original Message-----
> > >>>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On
> > Behalf
> > >Of Leif
> > >>>>> Lindholm
> > >>>>> Sent: Friday, November 08, 2019 2:37 AM
> > >>>>> To: Andrew Fish <afish@apple.com>
> > >>>>> Cc: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>;
> > >>>>> Ni, Ray <ray.ni@intel.com>; Justen, Jordan L
> > >>>>> <jordan.l.justen@intel.com>
> > >>>>> Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable
> > >>>>> CLANG9
> > >tool
> > >>>>> chain
> > >>>>>
> > >>>>> Hi Andrew,
> > >>>>>
> > >>>>> Yeah, I'm pretty easy with regards to what we change it to.
> > >>>>> Although if we're bikeshedding, I would prefer not using _ in
> > >>>>> the toolchain profile name.
> > >>>>>
> > >>>>> I'm ... optimistic ... it won't break any of my existing
> > >>>>> scripts, but since the build system uses it as a <toolchain
> > >>>>> profile>_<architecture>_<build target> separator, it would be
> > >>>>> profile>nice
> > >>>>> if we didn't risk confusion there.
> > >>>>>
> > >>>>> (I would be totally happy with PECLANG, CLANGPE, PDBCLANG,
> > >CLANGPDB or
> > >>>>> something along those lines.)
> > >>>>>
> > >>>>> Regards,
> > >>>>>
> > >>>>> Leif
> > >>>>>
> > >>>>> On Thu, Nov 07, 2019 at 11:54:04AM -0600, Andrew Fish wrote:
> > >>>>>> Leif,
> > >>>>>>
> > >>>>>> I think I proposed CLANG_PDB or CLANG_PECOFF. I seem to like
> > >>>>> CLANG_PDB as assuming the PDE debugging experience is
> > >awesome/exists
> > >>>>> on Linux and macOS is not a given.
> > >>>>>>
> > >>>>>> Thanks,
> > >>>>>>
> > >>>>>> Andrew Fish
> > >>>>>>
> > >>>>>>> On Nov 7, 2019, at 11:19 AM, Leif Lindholm
> > >>>>>>> <leif.lindholm@linaro.org>
> > >>>>> wrote:
> > >>>>>>>
> > >>>>>>> Oops, sorry, missed this in search.
> > >>>>>>>
> > >>>>>>> On Wed, Oct 30, 2019 at 03:43:44PM +0000, Liming Gao wrote:
> > >>>>>>>> Andrew:
> > >>>>>>>>
> > >>>>>>>> I prefer to keep short CLANG9 as the tool chain name. I add
> > >>>>>>>> wiki page
> > >>>>>>>>
> https://github.com/tianocore/tianocore.github.io/wiki/CLANG9-
> > >Tools-
> > >>>>> Chain
> > >>>>>>>> to introduce it.
> > >>>>>>>
> > >>>>>>> Why should users be expected to go and read documentation in
> > >order to
> > >>>>>>> learn that fundamental and incompatible changes to output and
> > >debug
> > >>>>>>> format has been made as part of what looks like a simple
> > >>>>>>> version
> > >bump?
> > >>>>>>>
> > >>>>>>>> And, we have CLANG38 tool chain. It generates ELF image and
> > >>>>>>>> DWARF debug symbol format. It can work with LLVM 9.0 release.
> > >>>>>>>> Current tool chain tag name includes compiler name and version.
> > >>>>>>>> There is no specific info in the tool chain name. The
> > >>>>>>>> developer can get the more tool chain information from wiki
> page.
> > >>>>>>>
> > >>>>>>> We aleady have the problem that people think they need to use
> > >GCC5 to
> > >>>>>>> build EDK2 since that is the highest named GCC toolchain profile.
> > >>>>>>>
> > >>>>>>> Let's not make this situation *worse* by setting up a
> > >multidimensional
> > >>>>>>> feature matrix, based off random numerical values.
> > >>>>>>>
> > >>>>>>> So say that we next have a pressing need to create a new
> > >>>>>>> toolchain profile for clang 10, using the old ELF mechanism.
> > >>>>>>> Are you then suggesting we set up a table on said wiki page
> > >>>>>>> where people have to
> > >go
> > >>>>>>> and look up what the object and debug formats are for each
> > >CLANG##
> > >>>>>>> toolchain profile?
> > >>>>>>>
> > >>>>>>> And what if you then end up needing to do the same for the PDB
> > >>>>>>> flavour?
> > >>>>>>>
> > >>>>>>>> CLANG9 is designed to support Emulator for Windows host only.
> > >>>>>>>
> > >>>>>>> Which is why it makes no sense to name it as a successor of
> > >>>>>>> CLANG38.
> > >>>>>>>
> > >>>>>>>> CLANG38 may be used for Emulator in Linux or Mac. I don’t try
> > >>>>>>>> it before.
> > >>>>>>>>
> > >>>>>>>> CLANG9 goal is to align the same compiler in the different
> > >>>>>>>> host development environment. It can replace VS or GCC
> > >>>>>>>> compiler. On Windows Host, I verify VS debugger for the source
> level debug.
> > >>>>>>>> On Linux host, I have not verified llvm debugger. I will
> > >>>>>>>> investigate the debugger solution for OVMF in Linux host.
> > >>>>>>>
> > >>>>>>> We are not asking you to throw out this toolchain profile.
> > >>>>>>>
> > >>>>>>> We are saying that since the functionality it provides is
> > >>>>>>> completely unrelated to that of CLANG38, it should not be
> > >>>>>>> named in a way that suggests it is merely a revision update.
> > >>>>>>>
> > >>>>>>> /
> > >>>>>>>   Leif
> > >>>>>>>
> > >>>>>>>> Thanks
> > >>>>>>>> Liming
> > >>>>>>>> From: afish@apple.com <afish@apple.com>
> > >>>>>>>> Sent: Saturday, October 26, 2019 2:45 AM
> > >>>>>>>> To: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>
> > >>>>>>>> Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L
> > >>>>> <jordan.l.justen@intel.com>
> > >>>>>>>> Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg:
> > >>>>>>>> Enable
> > >CLANG9
> > >>>>> tool chain
> > >>>>>>>>
> > >>>>>>>> Liming,
> > >>>>>>>>
> > >>>>>>>> Sorry I missed this mail. Thanks for the info! I was doing
> > >>>>>>>> some
> > >research
> > >>>>> into this too and now I think I finally understand. I think the
> > >>>>> name for
> > >the tool
> > >>>>> chain really confused me and we should think about changing the
> > name.
> > >>>>>>>>
> > >>>>>>>> From what I understand CLANG9 means produce PE/COFF
> directly
> > >and
> > >>>>> used the PDB debugging format. I see from the llvm site that the
> > >>>>> linker
> > >can
> > >>>>> produce PDB directly as you mention. This all makes sense to me
> > >>>>> now as
> > >LLVM
> > >>>>> tries to make it easy to be a drop in replacement for VC++ or GCC.
> > >>>>> So
> > >this tool
> > >>>>> chain is designed to be able to cross build a "Windows App" on a
> > >>>>> Linux or macOS. It also looks like the llvm debugger, lldb, is
> > >>>>> lagging in its support
> > >for
> > >>>>> PDB based debugging.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> Anyway I think Leif and I agree the toolchain name is very
> > confusing.
> > >I'd
> > >>>>> rather see it called CLANG9_WIN or CLANG_PDB.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Oct 18, 2019, at 7:27 AM, Liming Gao
> > >>>>> <liming.gao@intel.com<mailto:liming.gao@intel.com>> wrote:
> > >>>>>>>>
> > >>>>>>>> Andrew:
> > >>>>>>>> Here is the cover letter on CLANG9 introduction.
> > >>>>> https://edk2.groups.io/g/devel/message/49157
> > >>>>>>>>
> > >>>>>>>> 1)      Yes. CLANG9 tool chain is added to directly generate
> PE/COFF
> > >image
> > >>>>> (EFI image).
> > >>>>>>>> This tool chain uses LLVM clang C compiler and lld linker,
> > >>>>>>>> generates
> > >>>>> PE/COFF
> > >>>>>>>> image and PDB compatible debug symbol format. Now, it
> > supports
> > >>>>> IA32/X64 Archs.
> > >>>>>>>> LLVM clang C compiler and lld linker are the standalone tool set.
> > >They
> > >>>>> don’t depend other lib to generate PE/COFF image.
> > >>>>>>>>
> > >>>>>>>> 2)      Yes. CLANG9 is the cross OS tool chain. It can work on
> > >>>>> Windows/Linux/Mac host OS.
> > >>>>>>>> LLVM LLD linker uses Windows style arguments. I verify CLANG9
> > >>>>>>>> for
> > >>>>> Ovmf3264 in Windows/Linux host OS.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Linux can you source level debug Ovmf?
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> 3)     This patch enables WinHost in Windows. It doesn’t enable
> > >UnixHost.
> > >>>>> Now, EmulatorPkg with CLANG9 only works on Windows Host.
> > >>>>>>>> This patch can make other modules pass build in
> > >Windows/Linux/Mac
> > >>>>> only if LLVM9 tool set is installed.
> > >>>>>>>> But, the generated image may not work on Linux/Mac. I agree
> > >below
> > >>>>> linker flags are specific to windows host.
> > >>>>>>>> So, I suggest to add the conditional statement of
> > >$(WIN_HOST_BUILD)
> > >>>>> == TRUE for them.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> For the EmulatorPkg the Host is a native App for that OS you
> > >>>>>>>> build on,
> > >but
> > >>>>> it seems like CLANG9 is targeted to build Windows Apps. I'm not
> > >>>>> sure
> > >but you
> > >>>>> might be able to override all the linker commands to build a
> > >>>>> native app,
> > >or just
> > >>>>> use the system linker for the Host?
> > >>>>>>>>
> > >>>>>>>> I'm not sure how well debugging will work mixing PDB and
> > >>>>>>>> DWARF
> > >>>>> symbol formats?
> > >>>>>>>>
> > >>>>>>>> Thanks,
> > >>>>>>>>
> > >>>>>>>> Andrew Fish
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> !if $(WIN_HOST_BUILD) == TRUE
> > >>>>>>>> GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096
> > /FILEALIGN:4096
> > >>>>> /SUBSYSTEM:CONSOLE
> > >>>>>>>> GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
> > >>>>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> > >>>>>>>> GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
> > >>>>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> > >>>>>>>> !endif
> > >>>>>>>>
> > >>>>>>>> Thanks
> > >>>>>>>> Liming
> > >>>>>>>> From: afish@apple.com<mailto:afish@apple.com>
> > >>>>> <afish@apple.com<mailto:afish@apple.com>>
> > >>>>>>>> Sent: Friday, October 18, 2019 1:15 AM
> > >>>>>>>> To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > >>>>>>>> Cc: Gao, Liming
> > ><liming.gao@intel.com<mailto:liming.gao@intel.com>>;
> > >>>>> devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Justen,
> > Jordan
> > >>>>> L <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
> > >>>>>>>> Subject: Re: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool
> > >>>>>>>> chain
> > >>>>>>>>
> > >>>>>>>> Ray,
> > >>>>>>>>
> > >>>>>>>> Sorry I'm coming a little late to this and I'm confused. I
> > >>>>>>>> have some
> > >>>>> questions?
> > >>>>>>>> 1) Does CLANG9 imply CLANGPE?
> > >>>>>>>> 2) Does CLANGPE work on Linux and macOS? Can you pass the
> > >Windows
> > >>>>> style arguments to CLANGPE linker on Linux and macOS?
> > >>>>>>>> 3) For the EmulatorPkg don't you have the extra requirement
> > >>>>>>>> that
> > >>>>> compiler needs a standard C lib (or platform specific libs) to function?
> > >>>>>>>>      a) GCC:*_CLANG9_*_DLINK_FLAGS in EmulatorPkg.dsc
> seems
> > to
> > >>>>> imply the Linux and macOS systems will have a Windows SKD dir
> > >>>>> and a
> > >lot of
> > >>>>> Windows DLLs? Does all that come when you install CLANG9 when
> > you
> > >install
> > >>>>> it on Linux or macOS?
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> So I guess I'm asking is the linker really the same for
> > >>>>>>>> CLANG9 on all
> > >>>>> systems? I guess the answer could be yes, but it seems the C lib
> > >>>>> for the
> > >Host
> > >>>>> App is still an App for that OS and is OS dependent?
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> Sorry if I'm missing something fundamental and this is a dumb
> > >question.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> Thanks,
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> Andrew Fish
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Oct 17, 2019, at 12:27 AM, Ni, Ray
> > >>>>> <ray.ni@intel.com<mailto:ray.ni@intel.com>> wrote:
> > >>>>>>>>
> > >>>>>>>> Liming,
> > >>>>>>>> Emulator is using a generic SEC module. The host specific
> > >>>>>>>> module is
> > >called
> > >>>>> "Host".
> > >>>>>>>> So I prefer to change the macro to "WIN_HOST_BUILD", with
> > >>>>>>>> this
> > >change,
> > >>>>> Reviewed-by: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> -----Original Message-----
> > >>>>>>>> From: Gao, Liming
> > ><liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > >>>>>>>> Sent: Thursday, October 17, 2019 2:56 PM
> > >>>>>>>> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> > >>>>>>>> Cc: Justen, Jordan L
> > >>>>> <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>;
> > >Andrew
> > >>>>> Fish
> > >>>>>>>> <afish@apple.com<mailto:afish@apple.com>>; Ni, Ray
> > >>>>> <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > >>>>>>>> Subject: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool
> > >>>>>>>> chain
> > >>>>>>>>
> > >>>>>>>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
> > >>>>>>>> 1. Add WIN_SEC_BUILD macro check for CLANG9 tool chain build
> > >>>>>>>> -
> > p
> > >>>>>>>> EmulatorPkg\EmulatorPkg.dsc -a IA32 -DWIN_SEC_BUILD=TRUE
> -t
> > >>>>> CLANG9
> > >>>>>>>> build -p EmulatorPkg\EmulatorPkg.dsc -a X64 -
> > >DWIN_SEC_BUILD=TRUE -t
> > >>>>>>>> CLANG9 2. Append CLANG CC and LINK flags to generate
> windows
> > >HOST.
> > >>>>>>>> 3. Fix WinHost issue to call GetProcessAffinityMask() API.
> > >>>>>>>> The input parameter should be UINTN pointer instead of
> UINT32
> > >pointer.
> > >>>>>>>>
> > >>>>>>>> Cc: Jordan Justen
> > >>>>> <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
> > >>>>>>>> Cc: Andrew Fish <afish@apple.com<mailto:afish@apple.com>>
> > >>>>>>>> Cc: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > >>>>>>>> Signed-off-by: Liming Gao
> > >>>>> <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > >>>>>>>> ---
> > >>>>>>>> EmulatorPkg/Win/Host/WinHost.c   | 6 +++---
> > >>>>>>>> EmulatorPkg/EmulatorPkg.dsc      | 7 ++++++-
> > >>>>>>>> EmulatorPkg/Win/Host/WinHost.inf | 6 ++++++
> > >>>>>>>> 3 files changed, 15 insertions(+), 4 deletions(-)
> > >>>>>>>>
> > >>>>>>>> diff --git a/EmulatorPkg/Win/Host/WinHost.c
> > >>>>>>>> b/EmulatorPkg/Win/Host/WinHost.c index
> > 9aba3c8959..e40ce32548
> > >>>>> 100644
> > >>>>>>>> --- a/EmulatorPkg/Win/Host/WinHost.c
> > >>>>>>>> +++ b/EmulatorPkg/Win/Host/WinHost.c
> > >>>>>>>> @@ -356,7 +356,7 @@ Returns:
> > >>>>>>>> INTN
> > >>>>>>>> EFIAPI
> > >>>>>>>> main (
> > >>>>>>>> -  IN  INTN  Argc,
> > >>>>>>>> +  IN  INT  Argc,
> > >>>>>>>> IN  CHAR8 **Argv,
> > >>>>>>>> IN  CHAR8 **Envp
> > >>>>>>>> )
> > >>>>>>>> @@ -391,8 +391,8 @@ Returns:
> > >>>>>>>> VOID                  *SecFile;
> > >>>>>>>> CHAR16                *MemorySizeStr;
> > >>>>>>>> CHAR16                *FirmwareVolumesStr;
> > >>>>>>>> -  UINT32                ProcessAffinityMask;
> > >>>>>>>> -  UINT32                SystemAffinityMask;
> > >>>>>>>> +  UINTN                 ProcessAffinityMask;
> > >>>>>>>> +  UINTN                 SystemAffinityMask;
> > >>>>>>>> INT32                 LowBit;
> > >>>>>>>>
> > >>>>>>>> //
> > >>>>>>>> diff --git a/EmulatorPkg/EmulatorPkg.dsc
> > >>>>> b/EmulatorPkg/EmulatorPkg.dsc
> > >>>>>>>> index 20f1187713..72532f5daf 100644
> > >>>>>>>> --- a/EmulatorPkg/EmulatorPkg.dsc
> > >>>>>>>> +++ b/EmulatorPkg/EmulatorPkg.dsc
> > >>>>>>>> @@ -237,9 +237,10 @@
> > >>>>>>>>
> > >>>>>>>> [Components]
> > >>>>>>>> !if "IA32" in $(ARCH) || "X64" in $(ARCH)
> > >>>>>>>> -  !if "MSFT" in $(FAMILY)
> > >>>>>>>> +  !if "MSFT" in $(FAMILY) || $(WIN_SEC_BUILD) == TRUE
> > >>>>>>>>   ##
> > >>>>>>>>   #  Emulator, OS WIN application
> > >>>>>>>> +    #  CLANG9 is cross OS tool chain. It depends on
> > >>>>>>>> + WIN_SEC_BUILD
> > >>>>> macro.
> > >>>>>>>>   ##
> > >>>>>>>>   EmulatorPkg/Win/Host/WinHost.inf !else @@ -419,7 +420,11
> > @@
> > >>>>>>>>
> > >>>>>>>> MSFT:DEBUG_*_*_CC_FLAGS = /Od /Oy-
> > MSFT:NOOPT_*_*_CC_FLAGS =
> > >>>>>>>> /Od /Oy-
> > >>>>>>>> +  GCC:DEBUG_CLANG9_*_CC_FLAGS =-O0 -Wno-unused-
> > >command-
> > >>>>> line-
> > >>>>>>>> argument
> > >>>>>>>> + -Wno-incompatible-pointer-types -Wno-enum-conversion
> > >>>>>>>> + -Wno-incompatible-pointer-types -Wno-sometimes-
> > uninitialized
> > >>>>>>>> + -Wno-constant-conversion -Wno-main-return-type
> > >>>>>>>>
> > >>>>>>>> MSFT:*_*_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
> > >>>>>>>> /SUBSYSTEM:CONSOLE
> > >>>>>>>> MSFT:DEBUG_*_*_DLINK_FLAGS =
> > >>>>>>>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> /BASE:0x10000
> > >>>>>>>> MSFT:NOOPT_*_*_DLINK_FLAGS =
> > >>>>>>>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> /BASE:0x10000
> > >>>>>>>> +  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096
> > >/FILEALIGN:4096
> > >>>>>>>> /SUBSYSTEM:CONSOLE
> > >>>>>>>> +  GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
> > >>>>>>>> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> > /BASE:0x10000
> > >>>>>>>> + GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
> > >>>>>>>> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> > /BASE:0x10000
> > >>>>>>>> diff --git a/EmulatorPkg/Win/Host/WinHost.inf
> > >>>>>>>> b/EmulatorPkg/Win/Host/WinHost.inf
> > >>>>>>>> index 631d5a6470..1adca10d79 100644
> > >>>>>>>> --- a/EmulatorPkg/Win/Host/WinHost.inf
> > >>>>>>>> +++ b/EmulatorPkg/Win/Host/WinHost.inf
> > >>>>>>>> @@ -95,3 +95,9 @@
> > >>>>>>>> MSFT:*_VS2017_X64_DLINK_FLAGS      =
> > >>>>>>>> /LIBPATH:"%VCToolsInstallDir%lib\x64"
> > >>>>>>>>
> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
> > >>>>>>>>
> > >/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
> > >>>>>>>> /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB
> /IGNORE:4086
> > >/MAP
> > >>>>>>>> /OPT:REF /DEBUG /MACHINE:AMD64 /LTCG Kernel32.lib
> > >MSVCRTD.lib
> > >>>>>>>> vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib Winmm.lib
> > Advapi32.lib
> > >>>>>>>> MSFT:*_*_X64_ASM_FLAGS            == /nologo /W3 /WX /c /Cx
> /Zd
> > >/W0
> > >>>>> /Zi
> > >>>>>>>> MSFT:*_*_X64_ASMLINK_FLAGS        == /link /nologo
> > >>>>>>>> +
> > >>>>>>>> +  GCC:*_CLANG9_X64_DLINK_FLAGS ==
> > >>>>>>>> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
> > >>>>>>>> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> > >>>>>>>>
> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
> > >>>>>>>>
> > >/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
> > >>>>>>>> /LIBPATH:"%VCToolsInstallDir%lib\x64"   /NOLOGO
> > >>>>> /SUBSYSTEM:CONSOLE
> > >>>>>>>> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG
> > >/MACHINE:AMD64
> > >>>>>>>> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib
> > >User32.lib
> > >>>>>>>> Winmm.lib Advapi32.lib /lldmap
> > >>>>>>>> /EXPORT:InitializeDriver=_ModuleEntryPoint
> > >>>>>>>> +  GCC:*_CLANG9_X64_CC_FLAGS == -m64 -g -fshort-wchar
> > >>>>>>>> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
> > >>>>>>>> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path
> -D
> > >>>>> UNICODE
> > >>>>>>>> -D
> > >>>>>>>> + _CRT_SECURE_NO_DEPRECATE
> > >>>>>>>> +
> > >>>>>>>> +  GCC:*_CLANG9_IA32_DLINK_FLAGS ==
> > >>>>>>>> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
> > >>>>>>>> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> > >>>>>>>>
> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86"
> > >>>>>>>>
> > >/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86"
> > >>>>>>>> /LIBPATH:"%VCToolsInstallDir%ib\x86"   /NOLOGO
> > >>>>> /SUBSYSTEM:CONSOLE
> > >>>>>>>> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG
> /MACHINE:I386
> > >>>>>>>> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib
> > >User32.lib
> > >>>>>>>> Winmm.lib Advapi32.lib /lldmap
> > >>>>>>>> /EXPORT:InitializeDriver=_ModuleEntryPoint
> > >>>>>>>> +  GCC:*_CLANG9_IA32_CC_FLAGS == -m32 -g -fshort-wchar
> > >>>>>>>> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
> > >>>>>>>> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path
> -D
> > >>>>> UNICODE
> > >>>>>>>> -D
> > >>>>>>>> + _CRT_SECURE_NO_DEPRECATE
> > >>>>>>>> --
> > >>>>>>>> 2.13.0.windows.1
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>
> > >
> > >
> 
> 
> 

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

[Ni, Ray]

And LLVM I believe is capable to support generating PE + DWARF.
That's my second concern: Using CLANGPE may not imply PDB is used from a LLVM expert's understanding.


> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Ni, Ray
> Sent: Tuesday, November 12, 2019 11:10 AM
> To: devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com>; Gao, Liming
> <liming.gao@intel.com>; afish@apple.com; Leif Lindholm
> <leif.lindholm@linaro.org>
> Cc: Justen, Jordan L <jordan.l.justen@intel.com>; Shi, Steven
> <steven.shi@intel.com>
> Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool
> chain
> 
> My point is if we choose CLANGPE, for LLVM toolchain supporting DWARF
> debug symbol, there is no proper name left: we cannot use CLANGELF.
> 
> Andrew, you said CLANGPDE. A typo?
> 
> > -----Original Message-----
> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Ni,
> Ray
> > Sent: Tuesday, November 12, 2019 9:46 AM
> > To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io;
> > afish@apple.com; Leif Lindholm <leif.lindholm@linaro.org>
> > Cc: Justen, Jordan L <jordan.l.justen@intel.com>; Shi, Steven
> > <steven.shi@intel.com>
> > Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9
> > tool chain
> >
> > Liming,
> > What name will be chosen when in future someone wants a LLVM
> toolchain
> > which supports DWARF debug symbol?
> >
> >
> > > -----Original Message-----
> > > From: Gao, Liming <liming.gao@intel.com>
> > > Sent: Tuesday, November 12, 2019 8:41 AM
> > > To: devel@edk2.groups.io; afish@apple.com; Leif Lindholm
> > > <leif.lindholm@linaro.org>
> > > Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L
> > > <jordan.l.justen@intel.com>; Shi, Steven <steven.shi@intel.com>;
> > > Gao, Liming <liming.gao@intel.com>
> > > Subject: RE: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable
> > > CLANG9 tool chain
> > >
> > > Thanks for your feedback. I will choose CLANGPE as the tool chain name.
> > >
> > > Thanks
> > > Liming
> > > >-----Original Message-----
> > > >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf
> > > >Of Andrew Fish via Groups.Io
> > > >Sent: Tuesday, November 12, 2019 12:52 AM
> > > >To: Leif Lindholm <leif.lindholm@linaro.org>
> > > >Cc: Ni, Ray <ray.ni@intel.com>; Gao, Liming <liming.gao@intel.com>;
> > > >devel@edk2.groups.io; Justen, Jordan L <jordan.l.justen@intel.com>;
> > > >Shi, Steven <steven.shi@intel.com>
> > > >Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable
> > > >CLANG9 tool chain
> > > >
> > > >Either works for me too. I like the PDE ending a little more, but
> > > >agree it is a little more obscure.
> > > >> On Nov 11, 2019, at 8:39 AM, Leif Lindholm
> > > >> <leif.lindholm@linaro.org>
> > > wrote:
> > > >>
> > > >> On Fri, Nov 08, 2019 at 03:34:59AM +0000, Ni, Ray wrote:
> > > >>> Liming,
> > > >>> PE is UEFI spec required executable binary format. I like
> > > >>> CLANGPDB more than CLANGPE given LLVM may generate DRAWF
> debug
> > > >>> symbol
> > > >even
> > > >>> when generating PE.
> > > >>
> > > >> Just a comment here to point out that while (as I stated in reply
> > > >> to
> > > >> Liming) my preference would be CLANGPE, I see the logic in the
> > > >> above, and would be happy with either.
> > > >>
> > > >> (My reason for preferring CLANGPE is not exactly techincal - I
> > > >> just expect more people to know what PE is than who know what PDB
> > > >> is.)
> > > >>
> > > >> Regards,
> > > >>
> > > >> Leif
> > > >>
> > > >>>> -----Original Message-----
> > > >>>> From: Gao, Liming <liming.gao@intel.com>
> > > >>>> Sent: Friday, November 8, 2019 9:50 AM
> > > >>>> To: devel@edk2.groups.io; leif.lindholm@linaro.org; Andrew Fish
> > > ><afish@apple.com>
> > > >>>> Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L
> > > ><jordan.l.justen@intel.com>; Gao, Liming <liming.gao@intel.com>;
> > > >Shi,
> > > >>>> Steven <steven.shi@intel.com>
> > > >>>> Subject: RE: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable
> > > >>>> CLANG9
> > > >tool chain
> > > >>>>
> > > >>>> Andrew and Leif:
> > > >>>>  Thanks for your comment. CLANG9 is different from CLANG38.
> > > >>>> And,
> > > >CLANG9 will support LLVM9 or the above.
> > > >>>>  So, this tool chain should have the specific word for its
> > > >>>> purpose, and
> > > >remove the version 9 to avoid the confuse.
> > > >>>>
> > > >>>>  I prefer the tool chain name as CLANGPE or CLANGPDB. CLANGPE
> > may
> > > >be better. Now, CLANG9 tool chain
> > > >>>>  build rule family just uses CLANGPE. CLANGPE lets user know
> > > >>>> this tool
> > > >chain generates PE/COFF image.
> > > >>>>  And, PE/COFF image debug symbol is PDB. So, PE also means PDB.
> > > >>>>
> > > >>>>  Last, I just review the changes. Tool chain name update is not
> > > >>>> big. If you
> > > >accept CLANGPE as tool chain name,
> > > >>>>  I will send the patch soon to catch 201911 stable tag.
> > > >>>>
> > > >>>> Thanks
> > > >>>> Liming
> > > >>>>> -----Original Message-----
> > > >>>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On
> > > Behalf
> > > >Of Leif
> > > >>>>> Lindholm
> > > >>>>> Sent: Friday, November 08, 2019 2:37 AM
> > > >>>>> To: Andrew Fish <afish@apple.com>
> > > >>>>> Cc: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>;
> > > >>>>> Ni, Ray <ray.ni@intel.com>; Justen, Jordan L
> > > >>>>> <jordan.l.justen@intel.com>
> > > >>>>> Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable
> > > >>>>> CLANG9
> > > >tool
> > > >>>>> chain
> > > >>>>>
> > > >>>>> Hi Andrew,
> > > >>>>>
> > > >>>>> Yeah, I'm pretty easy with regards to what we change it to.
> > > >>>>> Although if we're bikeshedding, I would prefer not using _ in
> > > >>>>> the toolchain profile name.
> > > >>>>>
> > > >>>>> I'm ... optimistic ... it won't break any of my existing
> > > >>>>> scripts, but since the build system uses it as a <toolchain
> > > >>>>> profile>_<architecture>_<build target> separator, it would be
> > > >>>>> profile>nice
> > > >>>>> if we didn't risk confusion there.
> > > >>>>>
> > > >>>>> (I would be totally happy with PECLANG, CLANGPE, PDBCLANG,
> > > >CLANGPDB or
> > > >>>>> something along those lines.)
> > > >>>>>
> > > >>>>> Regards,
> > > >>>>>
> > > >>>>> Leif
> > > >>>>>
> > > >>>>> On Thu, Nov 07, 2019 at 11:54:04AM -0600, Andrew Fish wrote:
> > > >>>>>> Leif,
> > > >>>>>>
> > > >>>>>> I think I proposed CLANG_PDB or CLANG_PECOFF. I seem to like
> > > >>>>> CLANG_PDB as assuming the PDE debugging experience is
> > > >awesome/exists
> > > >>>>> on Linux and macOS is not a given.
> > > >>>>>>
> > > >>>>>> Thanks,
> > > >>>>>>
> > > >>>>>> Andrew Fish
> > > >>>>>>
> > > >>>>>>> On Nov 7, 2019, at 11:19 AM, Leif Lindholm
> > > >>>>>>> <leif.lindholm@linaro.org>
> > > >>>>> wrote:
> > > >>>>>>>
> > > >>>>>>> Oops, sorry, missed this in search.
> > > >>>>>>>
> > > >>>>>>> On Wed, Oct 30, 2019 at 03:43:44PM +0000, Liming Gao wrote:
> > > >>>>>>>> Andrew:
> > > >>>>>>>>
> > > >>>>>>>> I prefer to keep short CLANG9 as the tool chain name. I add
> > > >>>>>>>> wiki page
> > > >>>>>>>>
> > https://github.com/tianocore/tianocore.github.io/wiki/CLANG9-
> > > >Tools-
> > > >>>>> Chain
> > > >>>>>>>> to introduce it.
> > > >>>>>>>
> > > >>>>>>> Why should users be expected to go and read documentation
> in
> > > >order to
> > > >>>>>>> learn that fundamental and incompatible changes to output
> > > >>>>>>> and
> > > >debug
> > > >>>>>>> format has been made as part of what looks like a simple
> > > >>>>>>> version
> > > >bump?
> > > >>>>>>>
> > > >>>>>>>> And, we have CLANG38 tool chain. It generates ELF image and
> > > >>>>>>>> DWARF debug symbol format. It can work with LLVM 9.0
> release.
> > > >>>>>>>> Current tool chain tag name includes compiler name and
> version.
> > > >>>>>>>> There is no specific info in the tool chain name. The
> > > >>>>>>>> developer can get the more tool chain information from wiki
> > page.
> > > >>>>>>>
> > > >>>>>>> We aleady have the problem that people think they need to
> > > >>>>>>> use
> > > >GCC5 to
> > > >>>>>>> build EDK2 since that is the highest named GCC toolchain profile.
> > > >>>>>>>
> > > >>>>>>> Let's not make this situation *worse* by setting up a
> > > >multidimensional
> > > >>>>>>> feature matrix, based off random numerical values.
> > > >>>>>>>
> > > >>>>>>> So say that we next have a pressing need to create a new
> > > >>>>>>> toolchain profile for clang 10, using the old ELF mechanism.
> > > >>>>>>> Are you then suggesting we set up a table on said wiki page
> > > >>>>>>> where people have to
> > > >go
> > > >>>>>>> and look up what the object and debug formats are for each
> > > >CLANG##
> > > >>>>>>> toolchain profile?
> > > >>>>>>>
> > > >>>>>>> And what if you then end up needing to do the same for the
> > > >>>>>>> PDB flavour?
> > > >>>>>>>
> > > >>>>>>>> CLANG9 is designed to support Emulator for Windows host
> only.
> > > >>>>>>>
> > > >>>>>>> Which is why it makes no sense to name it as a successor of
> > > >>>>>>> CLANG38.
> > > >>>>>>>
> > > >>>>>>>> CLANG38 may be used for Emulator in Linux or Mac. I don’t
> > > >>>>>>>> try it before.
> > > >>>>>>>>
> > > >>>>>>>> CLANG9 goal is to align the same compiler in the different
> > > >>>>>>>> host development environment. It can replace VS or GCC
> > > >>>>>>>> compiler. On Windows Host, I verify VS debugger for the
> > > >>>>>>>> source
> > level debug.
> > > >>>>>>>> On Linux host, I have not verified llvm debugger. I will
> > > >>>>>>>> investigate the debugger solution for OVMF in Linux host.
> > > >>>>>>>
> > > >>>>>>> We are not asking you to throw out this toolchain profile.
> > > >>>>>>>
> > > >>>>>>> We are saying that since the functionality it provides is
> > > >>>>>>> completely unrelated to that of CLANG38, it should not be
> > > >>>>>>> named in a way that suggests it is merely a revision update.
> > > >>>>>>>
> > > >>>>>>> /
> > > >>>>>>>   Leif
> > > >>>>>>>
> > > >>>>>>>> Thanks
> > > >>>>>>>> Liming
> > > >>>>>>>> From: afish@apple.com <afish@apple.com>
> > > >>>>>>>> Sent: Saturday, October 26, 2019 2:45 AM
> > > >>>>>>>> To: devel@edk2.groups.io; Gao, Liming
> > > >>>>>>>> <liming.gao@intel.com>
> > > >>>>>>>> Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L
> > > >>>>> <jordan.l.justen@intel.com>
> > > >>>>>>>> Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg:
> > > >>>>>>>> Enable
> > > >CLANG9
> > > >>>>> tool chain
> > > >>>>>>>>
> > > >>>>>>>> Liming,
> > > >>>>>>>>
> > > >>>>>>>> Sorry I missed this mail. Thanks for the info! I was doing
> > > >>>>>>>> some
> > > >research
> > > >>>>> into this too and now I think I finally understand. I think
> > > >>>>> the name for
> > > >the tool
> > > >>>>> chain really confused me and we should think about changing
> > > >>>>> the
> > > name.
> > > >>>>>>>>
> > > >>>>>>>> From what I understand CLANG9 means produce PE/COFF
> > directly
> > > >and
> > > >>>>> used the PDB debugging format. I see from the llvm site that
> > > >>>>> the linker
> > > >can
> > > >>>>> produce PDB directly as you mention. This all makes sense to
> > > >>>>> me now as
> > > >LLVM
> > > >>>>> tries to make it easy to be a drop in replacement for VC++ or GCC.
> > > >>>>> So
> > > >this tool
> > > >>>>> chain is designed to be able to cross build a "Windows App" on
> > > >>>>> a Linux or macOS. It also looks like the llvm debugger, lldb,
> > > >>>>> is lagging in its support
> > > >for
> > > >>>>> PDB based debugging.
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> Anyway I think Leif and I agree the toolchain name is very
> > > confusing.
> > > >I'd
> > > >>>>> rather see it called CLANG9_WIN or CLANG_PDB.
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> On Oct 18, 2019, at 7:27 AM, Liming Gao
> > > >>>>> <liming.gao@intel.com<mailto:liming.gao@intel.com>> wrote:
> > > >>>>>>>>
> > > >>>>>>>> Andrew:
> > > >>>>>>>> Here is the cover letter on CLANG9 introduction.
> > > >>>>> https://edk2.groups.io/g/devel/message/49157
> > > >>>>>>>>
> > > >>>>>>>> 1)      Yes. CLANG9 tool chain is added to directly generate
> > PE/COFF
> > > >image
> > > >>>>> (EFI image).
> > > >>>>>>>> This tool chain uses LLVM clang C compiler and lld linker,
> > > >>>>>>>> generates
> > > >>>>> PE/COFF
> > > >>>>>>>> image and PDB compatible debug symbol format. Now, it
> > > supports
> > > >>>>> IA32/X64 Archs.
> > > >>>>>>>> LLVM clang C compiler and lld linker are the standalone tool
> set.
> > > >They
> > > >>>>> don’t depend other lib to generate PE/COFF image.
> > > >>>>>>>>
> > > >>>>>>>> 2)      Yes. CLANG9 is the cross OS tool chain. It can work on
> > > >>>>> Windows/Linux/Mac host OS.
> > > >>>>>>>> LLVM LLD linker uses Windows style arguments. I verify
> > > >>>>>>>> CLANG9 for
> > > >>>>> Ovmf3264 in Windows/Linux host OS.
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> On Linux can you source level debug Ovmf?
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> 3)     This patch enables WinHost in Windows. It doesn’t enable
> > > >UnixHost.
> > > >>>>> Now, EmulatorPkg with CLANG9 only works on Windows Host.
> > > >>>>>>>> This patch can make other modules pass build in
> > > >Windows/Linux/Mac
> > > >>>>> only if LLVM9 tool set is installed.
> > > >>>>>>>> But, the generated image may not work on Linux/Mac. I agree
> > > >below
> > > >>>>> linker flags are specific to windows host.
> > > >>>>>>>> So, I suggest to add the conditional statement of
> > > >$(WIN_HOST_BUILD)
> > > >>>>> == TRUE for them.
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> For the EmulatorPkg the Host is a native App for that OS
> > > >>>>>>>> you build on,
> > > >but
> > > >>>>> it seems like CLANG9 is targeted to build Windows Apps. I'm
> > > >>>>> not sure
> > > >but you
> > > >>>>> might be able to override all the linker commands to build a
> > > >>>>> native app,
> > > >or just
> > > >>>>> use the system linker for the Host?
> > > >>>>>>>>
> > > >>>>>>>> I'm not sure how well debugging will work mixing PDB and
> > > >>>>>>>> DWARF
> > > >>>>> symbol formats?
> > > >>>>>>>>
> > > >>>>>>>> Thanks,
> > > >>>>>>>>
> > > >>>>>>>> Andrew Fish
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> !if $(WIN_HOST_BUILD) == TRUE
> > > >>>>>>>> GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096
> > > /FILEALIGN:4096
> > > >>>>> /SUBSYSTEM:CONSOLE
> > > >>>>>>>> GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
> > > >>>>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> > > >>>>>>>> GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
> > > >>>>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> > > >>>>>>>> !endif
> > > >>>>>>>>
> > > >>>>>>>> Thanks
> > > >>>>>>>> Liming
> > > >>>>>>>> From: afish@apple.com<mailto:afish@apple.com>
> > > >>>>> <afish@apple.com<mailto:afish@apple.com>>
> > > >>>>>>>> Sent: Friday, October 18, 2019 1:15 AM
> > > >>>>>>>> To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > > >>>>>>>> Cc: Gao, Liming
> > > ><liming.gao@intel.com<mailto:liming.gao@intel.com>>;
> > > >>>>> devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Justen,
> > > Jordan
> > > >>>>> L
> > > >>>>> <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
> > > >>>>>>>> Subject: Re: [Patch v3 10/11] EmulatorPkg: Enable CLANG9
> > > >>>>>>>> tool chain
> > > >>>>>>>>
> > > >>>>>>>> Ray,
> > > >>>>>>>>
> > > >>>>>>>> Sorry I'm coming a little late to this and I'm confused. I
> > > >>>>>>>> have some
> > > >>>>> questions?
> > > >>>>>>>> 1) Does CLANG9 imply CLANGPE?
> > > >>>>>>>> 2) Does CLANGPE work on Linux and macOS? Can you pass the
> > > >Windows
> > > >>>>> style arguments to CLANGPE linker on Linux and macOS?
> > > >>>>>>>> 3) For the EmulatorPkg don't you have the extra requirement
> > > >>>>>>>> that
> > > >>>>> compiler needs a standard C lib (or platform specific libs) to
> function?
> > > >>>>>>>>      a) GCC:*_CLANG9_*_DLINK_FLAGS in EmulatorPkg.dsc
> > seems
> > > to
> > > >>>>> imply the Linux and macOS systems will have a Windows SKD dir
> > > >>>>> and a
> > > >lot of
> > > >>>>> Windows DLLs? Does all that come when you install CLANG9 when
> > > you
> > > >install
> > > >>>>> it on Linux or macOS?
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> So I guess I'm asking is the linker really the same for
> > > >>>>>>>> CLANG9 on all
> > > >>>>> systems? I guess the answer could be yes, but it seems the C
> > > >>>>> lib for the
> > > >Host
> > > >>>>> App is still an App for that OS and is OS dependent?
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> Sorry if I'm missing something fundamental and this is a
> > > >>>>>>>> dumb
> > > >question.
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> Thanks,
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> Andrew Fish
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> On Oct 17, 2019, at 12:27 AM, Ni, Ray
> > > >>>>> <ray.ni@intel.com<mailto:ray.ni@intel.com>> wrote:
> > > >>>>>>>>
> > > >>>>>>>> Liming,
> > > >>>>>>>> Emulator is using a generic SEC module. The host specific
> > > >>>>>>>> module is
> > > >called
> > > >>>>> "Host".
> > > >>>>>>>> So I prefer to change the macro to "WIN_HOST_BUILD", with
> > > >>>>>>>> this
> > > >change,
> > > >>>>> Reviewed-by: Ray Ni
> > > >>>>> <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> -----Original Message-----
> > > >>>>>>>> From: Gao, Liming
> > > ><liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > >>>>>>>> Sent: Thursday, October 17, 2019 2:56 PM
> > > >>>>>>>> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> > > >>>>>>>> Cc: Justen, Jordan L
> > > >>>>> <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>;
> > > >Andrew
> > > >>>>> Fish
> > > >>>>>>>> <afish@apple.com<mailto:afish@apple.com>>; Ni, Ray
> > > >>>>> <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > > >>>>>>>> Subject: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool
> > > >>>>>>>> chain
> > > >>>>>>>>
> > > >>>>>>>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
> > > >>>>>>>> 1. Add WIN_SEC_BUILD macro check for CLANG9 tool chain
> > > >>>>>>>> build
> > > >>>>>>>> -
> > > p
> > > >>>>>>>> EmulatorPkg\EmulatorPkg.dsc -a IA32 -
> DWIN_SEC_BUILD=TRUE
> > -t
> > > >>>>> CLANG9
> > > >>>>>>>> build -p EmulatorPkg\EmulatorPkg.dsc -a X64 -
> > > >DWIN_SEC_BUILD=TRUE -t
> > > >>>>>>>> CLANG9 2. Append CLANG CC and LINK flags to generate
> > windows
> > > >HOST.
> > > >>>>>>>> 3. Fix WinHost issue to call GetProcessAffinityMask() API.
> > > >>>>>>>> The input parameter should be UINTN pointer instead of
> > UINT32
> > > >pointer.
> > > >>>>>>>>
> > > >>>>>>>> Cc: Jordan Justen
> > > >>>>> <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
> > > >>>>>>>> Cc: Andrew Fish <afish@apple.com<mailto:afish@apple.com>>
> > > >>>>>>>> Cc: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > > >>>>>>>> Signed-off-by: Liming Gao
> > > >>>>> <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > >>>>>>>> ---
> > > >>>>>>>> EmulatorPkg/Win/Host/WinHost.c   | 6 +++---
> > > >>>>>>>> EmulatorPkg/EmulatorPkg.dsc      | 7 ++++++-
> > > >>>>>>>> EmulatorPkg/Win/Host/WinHost.inf | 6 ++++++
> > > >>>>>>>> 3 files changed, 15 insertions(+), 4 deletions(-)
> > > >>>>>>>>
> > > >>>>>>>> diff --git a/EmulatorPkg/Win/Host/WinHost.c
> > > >>>>>>>> b/EmulatorPkg/Win/Host/WinHost.c index
> > > 9aba3c8959..e40ce32548
> > > >>>>> 100644
> > > >>>>>>>> --- a/EmulatorPkg/Win/Host/WinHost.c
> > > >>>>>>>> +++ b/EmulatorPkg/Win/Host/WinHost.c
> > > >>>>>>>> @@ -356,7 +356,7 @@ Returns:
> > > >>>>>>>> INTN
> > > >>>>>>>> EFIAPI
> > > >>>>>>>> main (
> > > >>>>>>>> -  IN  INTN  Argc,
> > > >>>>>>>> +  IN  INT  Argc,
> > > >>>>>>>> IN  CHAR8 **Argv,
> > > >>>>>>>> IN  CHAR8 **Envp
> > > >>>>>>>> )
> > > >>>>>>>> @@ -391,8 +391,8 @@ Returns:
> > > >>>>>>>> VOID                  *SecFile;
> > > >>>>>>>> CHAR16                *MemorySizeStr;
> > > >>>>>>>> CHAR16                *FirmwareVolumesStr;
> > > >>>>>>>> -  UINT32                ProcessAffinityMask;
> > > >>>>>>>> -  UINT32                SystemAffinityMask;
> > > >>>>>>>> +  UINTN                 ProcessAffinityMask;
> > > >>>>>>>> +  UINTN                 SystemAffinityMask;
> > > >>>>>>>> INT32                 LowBit;
> > > >>>>>>>>
> > > >>>>>>>> //
> > > >>>>>>>> diff --git a/EmulatorPkg/EmulatorPkg.dsc
> > > >>>>> b/EmulatorPkg/EmulatorPkg.dsc
> > > >>>>>>>> index 20f1187713..72532f5daf 100644
> > > >>>>>>>> --- a/EmulatorPkg/EmulatorPkg.dsc
> > > >>>>>>>> +++ b/EmulatorPkg/EmulatorPkg.dsc
> > > >>>>>>>> @@ -237,9 +237,10 @@
> > > >>>>>>>>
> > > >>>>>>>> [Components]
> > > >>>>>>>> !if "IA32" in $(ARCH) || "X64" in $(ARCH)
> > > >>>>>>>> -  !if "MSFT" in $(FAMILY)
> > > >>>>>>>> +  !if "MSFT" in $(FAMILY) || $(WIN_SEC_BUILD) == TRUE
> > > >>>>>>>>   ##
> > > >>>>>>>>   #  Emulator, OS WIN application
> > > >>>>>>>> +    #  CLANG9 is cross OS tool chain. It depends on
> > > >>>>>>>> + WIN_SEC_BUILD
> > > >>>>> macro.
> > > >>>>>>>>   ##
> > > >>>>>>>>   EmulatorPkg/Win/Host/WinHost.inf !else @@ -419,7 +420,11
> > > @@
> > > >>>>>>>>
> > > >>>>>>>> MSFT:DEBUG_*_*_CC_FLAGS = /Od /Oy-
> > > MSFT:NOOPT_*_*_CC_FLAGS =
> > > >>>>>>>> /Od /Oy-
> > > >>>>>>>> +  GCC:DEBUG_CLANG9_*_CC_FLAGS =-O0 -Wno-unused-
> > > >command-
> > > >>>>> line-
> > > >>>>>>>> argument
> > > >>>>>>>> + -Wno-incompatible-pointer-types -Wno-enum-conversion
> > > >>>>>>>> + -Wno-incompatible-pointer-types -Wno-sometimes-
> > > uninitialized
> > > >>>>>>>> + -Wno-constant-conversion -Wno-main-return-type
> > > >>>>>>>>
> > > >>>>>>>> MSFT:*_*_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
> > > >>>>>>>> /SUBSYSTEM:CONSOLE
> > > >>>>>>>> MSFT:DEBUG_*_*_DLINK_FLAGS =
> > > >>>>>>>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> > /BASE:0x10000
> > > >>>>>>>> MSFT:NOOPT_*_*_DLINK_FLAGS =
> > > >>>>>>>> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> > /BASE:0x10000
> > > >>>>>>>> +  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096
> > > >/FILEALIGN:4096
> > > >>>>>>>> /SUBSYSTEM:CONSOLE
> > > >>>>>>>> +  GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
> > > >>>>>>>> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> > > /BASE:0x10000
> > > >>>>>>>> + GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
> > > >>>>>>>> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> > > /BASE:0x10000
> > > >>>>>>>> diff --git a/EmulatorPkg/Win/Host/WinHost.inf
> > > >>>>>>>> b/EmulatorPkg/Win/Host/WinHost.inf
> > > >>>>>>>> index 631d5a6470..1adca10d79 100644
> > > >>>>>>>> --- a/EmulatorPkg/Win/Host/WinHost.inf
> > > >>>>>>>> +++ b/EmulatorPkg/Win/Host/WinHost.inf
> > > >>>>>>>> @@ -95,3 +95,9 @@
> > > >>>>>>>> MSFT:*_VS2017_X64_DLINK_FLAGS      =
> > > >>>>>>>> /LIBPATH:"%VCToolsInstallDir%lib\x64"
> > > >>>>>>>>
> > /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
> > > >>>>>>>>
> > > >/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
> > > >>>>>>>> /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB
> > /IGNORE:4086
> > > >/MAP
> > > >>>>>>>> /OPT:REF /DEBUG /MACHINE:AMD64 /LTCG Kernel32.lib
> > > >MSVCRTD.lib
> > > >>>>>>>> vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib Winmm.lib
> > > Advapi32.lib
> > > >>>>>>>> MSFT:*_*_X64_ASM_FLAGS            == /nologo /W3 /WX /c /Cx
> > /Zd
> > > >/W0
> > > >>>>> /Zi
> > > >>>>>>>> MSFT:*_*_X64_ASMLINK_FLAGS        == /link /nologo
> > > >>>>>>>> +
> > > >>>>>>>> +  GCC:*_CLANG9_X64_DLINK_FLAGS ==
> > > >>>>>>>> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
> > > >>>>>>>> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> > > >>>>>>>>
> > /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
> > > >>>>>>>>
> > > >/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
> > > >>>>>>>> /LIBPATH:"%VCToolsInstallDir%lib\x64"   /NOLOGO
> > > >>>>> /SUBSYSTEM:CONSOLE
> > > >>>>>>>> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG
> > > >/MACHINE:AMD64
> > > >>>>>>>> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib
> > > >User32.lib
> > > >>>>>>>> Winmm.lib Advapi32.lib /lldmap
> > > >>>>>>>> /EXPORT:InitializeDriver=_ModuleEntryPoint
> > > >>>>>>>> +  GCC:*_CLANG9_X64_CC_FLAGS == -m64 -g -fshort-wchar
> > > >>>>>>>> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
> > > >>>>>>>> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-
> path
> > -D
> > > >>>>> UNICODE
> > > >>>>>>>> -D
> > > >>>>>>>> + _CRT_SECURE_NO_DEPRECATE
> > > >>>>>>>> +
> > > >>>>>>>> +  GCC:*_CLANG9_IA32_DLINK_FLAGS ==
> > > >>>>>>>> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
> > > >>>>>>>> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> > > >>>>>>>>
> > /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86"
> > > >>>>>>>>
> > > >/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86"
> > > >>>>>>>> /LIBPATH:"%VCToolsInstallDir%ib\x86"   /NOLOGO
> > > >>>>> /SUBSYSTEM:CONSOLE
> > > >>>>>>>> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG
> > /MACHINE:I386
> > > >>>>>>>> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib
> > > >User32.lib
> > > >>>>>>>> Winmm.lib Advapi32.lib /lldmap
> > > >>>>>>>> /EXPORT:InitializeDriver=_ModuleEntryPoint
> > > >>>>>>>> +  GCC:*_CLANG9_IA32_CC_FLAGS == -m32 -g -fshort-wchar
> > > >>>>>>>> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
> > > >>>>>>>> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-
> path
> > -D
> > > >>>>> UNICODE
> > > >>>>>>>> -D
> > > >>>>>>>> + _CRT_SECURE_NO_DEPRECATE
> > > >>>>>>>> --
> > > >>>>>>>> 2.13.0.windows.1
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>
> > > >
> > > >
> >
> >
> >
> 
> 
> 

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

[Michael D Kinney]

Ray,

I agree that a name that represents the symbolic debug
format makes more sense.

The term 'PE' is short for PE/COFF, and that is the 
required final output format.  A toolchain profile that
happens to go through other intermediate formats (e.g. 
elf or macho) before finally generating a PE/COFF image
is usually not that interesting to most developers.  So
adding 'PE' to the name is redundant information.

The attribute of the images that does impact developers
is the format of the symbol information.  Even for 
Visual Studio, PDB is the file extension used when the
symbol information is placed in a separate file.  The
Visual Studio compilers do support putting the symbol
information in a section of the PE/COFF image.  EDK II
builds happen to always use the PDB option to minimize
the size of firmware images. So PDB may not be the right
name either.  I think the symbol format in the PDB that
is used is codeview.

If we want to plan ahead for toolchain names perhaps:

Codeview: CLANGCODEVIEW or CLANGCV or CLANGPDB 
Dwarf:    CLANGDWARF

Best regards,

Mike

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On
> Behalf Of Ni, Ray
> Sent: Monday, November 11, 2019 7:23 PM
> To: devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com>;
> Gao, Liming <liming.gao@intel.com>; afish@apple.com;
> Leif Lindholm <leif.lindholm@linaro.org>
> Cc: Justen, Jordan L <jordan.l.justen@intel.com>; Shi,
> Steven <steven.shi@intel.com>
> Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg:
> Enable CLANG9 tool chain
> 
> And LLVM I believe is capable to support generating PE +
> DWARF.
> That's my second concern: Using CLANGPE may not imply
> PDB is used from a LLVM expert's understanding.
> 
> 
> > -----Original Message-----
> > From: devel@edk2.groups.io <devel@edk2.groups.io> On
> Behalf Of Ni, Ray
> > Sent: Tuesday, November 12, 2019 11:10 AM
> > To: devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com>;
> Gao, Liming
> > <liming.gao@intel.com>; afish@apple.com; Leif Lindholm
> > <leif.lindholm@linaro.org>
> > Cc: Justen, Jordan L <jordan.l.justen@intel.com>; Shi,
> Steven
> > <steven.shi@intel.com>
> > Subject: Re: [edk2-devel] [Patch v3 10/11]
> EmulatorPkg: Enable CLANG9
> > tool chain
> >
> > My point is if we choose CLANGPE, for LLVM toolchain
> supporting DWARF
> > debug symbol, there is no proper name left: we cannot
> use CLANGELF.
> >
> > Andrew, you said CLANGPDE. A typo?
> >
> > > -----Original Message-----
> > > From: devel@edk2.groups.io <devel@edk2.groups.io> On
> Behalf Of Ni,
> > Ray
> > > Sent: Tuesday, November 12, 2019 9:46 AM
> > > To: Gao, Liming <liming.gao@intel.com>;
> devel@edk2.groups.io;
> > > afish@apple.com; Leif Lindholm
> <leif.lindholm@linaro.org>
> > > Cc: Justen, Jordan L <jordan.l.justen@intel.com>;
> Shi, Steven
> > > <steven.shi@intel.com>
> > > Subject: Re: [edk2-devel] [Patch v3 10/11]
> EmulatorPkg: Enable
> > > CLANG9 tool chain
> > >
> > > Liming,
> > > What name will be chosen when in future someone
> wants a LLVM
> > toolchain
> > > which supports DWARF debug symbol?
> > >
> > >
> > > > -----Original Message-----
> > > > From: Gao, Liming <liming.gao@intel.com>
> > > > Sent: Tuesday, November 12, 2019 8:41 AM
> > > > To: devel@edk2.groups.io; afish@apple.com; Leif
> Lindholm
> > > > <leif.lindholm@linaro.org>
> > > > Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L
> > > > <jordan.l.justen@intel.com>; Shi, Steven
> <steven.shi@intel.com>;
> > > > Gao, Liming <liming.gao@intel.com>
> > > > Subject: RE: [edk2-devel] [Patch v3 10/11]
> EmulatorPkg: Enable
> > > > CLANG9 tool chain
> > > >
> > > > Thanks for your feedback. I will choose CLANGPE as
> the tool chain name.
> > > >
> > > > Thanks
> > > > Liming
> > > > >-----Original Message-----
> > > > >From: devel@edk2.groups.io
> [mailto:devel@edk2.groups.io] On
> > > > >Behalf Of Andrew Fish via Groups.Io
> > > > >Sent: Tuesday, November 12, 2019 12:52 AM
> > > > >To: Leif Lindholm <leif.lindholm@linaro.org>
> > > > >Cc: Ni, Ray <ray.ni@intel.com>; Gao, Liming
> > > > ><liming.gao@intel.com>; devel@edk2.groups.io;
> Justen, Jordan L
> > > > ><jordan.l.justen@intel.com>; Shi, Steven
> <steven.shi@intel.com>
> > > > >Subject: Re: [edk2-devel] [Patch v3 10/11]
> EmulatorPkg: Enable
> > > > >CLANG9 tool chain
> > > > >
> > > > >Either works for me too. I like the PDE ending a
> little more, but
> > > > >agree it is a little more obscure.
> > > > >> On Nov 11, 2019, at 8:39 AM, Leif Lindholm
> > > > >> <leif.lindholm@linaro.org>
> > > > wrote:
> > > > >>
> > > > >> On Fri, Nov 08, 2019 at 03:34:59AM +0000, Ni,
> Ray wrote:
> > > > >>> Liming,
> > > > >>> PE is UEFI spec required executable binary
> format. I like
> > > > >>> CLANGPDB more than CLANGPE given LLVM may
> generate DRAWF
> > debug
> > > > >>> symbol
> > > > >even
> > > > >>> when generating PE.
> > > > >>
> > > > >> Just a comment here to point out that while (as
> I stated in
> > > > >> reply to
> > > > >> Liming) my preference would be CLANGPE, I see
> the logic in the
> > > > >> above, and would be happy with either.
> > > > >>
> > > > >> (My reason for preferring CLANGPE is not
> exactly techincal - I
> > > > >> just expect more people to know what PE is than
> who know what
> > > > >> PDB
> > > > >> is.)
> > > > >>
> > > > >> Regards,
> > > > >>
> > > > >> Leif
> > > > >>
> > > > >>>> -----Original Message-----
> > > > >>>> From: Gao, Liming <liming.gao@intel.com>
> > > > >>>> Sent: Friday, November 8, 2019 9:50 AM
> > > > >>>> To: devel@edk2.groups.io;
> leif.lindholm@linaro.org; Andrew
> > > > >>>> Fish
> > > > ><afish@apple.com>
> > > > >>>> Cc: Ni, Ray <ray.ni@intel.com>; Justen,
> Jordan L
> > > > ><jordan.l.justen@intel.com>; Gao, Liming
> <liming.gao@intel.com>;
> > > > >Shi,
> > > > >>>> Steven <steven.shi@intel.com>
> > > > >>>> Subject: RE: [edk2-devel] [Patch v3 10/11]
> EmulatorPkg:
> > > > >>>> Enable
> > > > >>>> CLANG9
> > > > >tool chain
> > > > >>>>
> > > > >>>> Andrew and Leif:
> > > > >>>>  Thanks for your comment. CLANG9 is different
> from CLANG38.
> > > > >>>> And,
> > > > >CLANG9 will support LLVM9 or the above.
> > > > >>>>  So, this tool chain should have the specific
> word for its
> > > > >>>> purpose, and
> > > > >remove the version 9 to avoid the confuse.
> > > > >>>>
> > > > >>>>  I prefer the tool chain name as CLANGPE or
> CLANGPDB. CLANGPE
> > > may
> > > > >be better. Now, CLANG9 tool chain
> > > > >>>>  build rule family just uses CLANGPE. CLANGPE
> lets user know
> > > > >>>> this tool
> > > > >chain generates PE/COFF image.
> > > > >>>>  And, PE/COFF image debug symbol is PDB. So,
> PE also means PDB.
> > > > >>>>
> > > > >>>>  Last, I just review the changes. Tool chain
> name update is
> > > > >>>> not big. If you
> > > > >accept CLANGPE as tool chain name,
> > > > >>>>  I will send the patch soon to catch 201911
> stable tag.
> > > > >>>>
> > > > >>>> Thanks
> > > > >>>> Liming
> > > > >>>>> -----Original Message-----
> > > > >>>>> From: devel@edk2.groups.io
> [mailto:devel@edk2.groups.io] On
> > > > Behalf
> > > > >Of Leif
> > > > >>>>> Lindholm
> > > > >>>>> Sent: Friday, November 08, 2019 2:37 AM
> > > > >>>>> To: Andrew Fish <afish@apple.com>
> > > > >>>>> Cc: devel@edk2.groups.io; Gao, Liming
> > > > >>>>> <liming.gao@intel.com>; Ni, Ray
> <ray.ni@intel.com>; Justen,
> > > > >>>>> Jordan L <jordan.l.justen@intel.com>
> > > > >>>>> Subject: Re: [edk2-devel] [Patch v3 10/11]
> EmulatorPkg:
> > > > >>>>> Enable
> > > > >>>>> CLANG9
> > > > >tool
> > > > >>>>> chain
> > > > >>>>>
> > > > >>>>> Hi Andrew,
> > > > >>>>>
> > > > >>>>> Yeah, I'm pretty easy with regards to what
> we change it to.
> > > > >>>>> Although if we're bikeshedding, I would
> prefer not using _
> > > > >>>>> in the toolchain profile name.
> > > > >>>>>
> > > > >>>>> I'm ... optimistic ... it won't break any of
> my existing
> > > > >>>>> scripts, but since the build system uses it
> as a <toolchain
> > > > >>>>> profile>_<architecture>_<build target>
> separator, it would
> > > > >>>>> profile>be nice
> > > > >>>>> if we didn't risk confusion there.
> > > > >>>>>
> > > > >>>>> (I would be totally happy with PECLANG,
> CLANGPE, PDBCLANG,
> > > > >CLANGPDB or
> > > > >>>>> something along those lines.)
> > > > >>>>>
> > > > >>>>> Regards,
> > > > >>>>>
> > > > >>>>> Leif
> > > > >>>>>
> > > > >>>>> On Thu, Nov 07, 2019 at 11:54:04AM -0600,
> Andrew Fish wrote:
> > > > >>>>>> Leif,
> > > > >>>>>>
> > > > >>>>>> I think I proposed CLANG_PDB or
> CLANG_PECOFF. I seem to
> > > > >>>>>> like
> > > > >>>>> CLANG_PDB as assuming the PDE debugging
> experience is
> > > > >awesome/exists
> > > > >>>>> on Linux and macOS is not a given.
> > > > >>>>>>
> > > > >>>>>> Thanks,
> > > > >>>>>>
> > > > >>>>>> Andrew Fish
> > > > >>>>>>
> > > > >>>>>>> On Nov 7, 2019, at 11:19 AM, Leif Lindholm
> > > > >>>>>>> <leif.lindholm@linaro.org>
> > > > >>>>> wrote:
> > > > >>>>>>>
> > > > >>>>>>> Oops, sorry, missed this in search.
> > > > >>>>>>>
> > > > >>>>>>> On Wed, Oct 30, 2019 at 03:43:44PM +0000,
> Liming Gao wrote:
> > > > >>>>>>>> Andrew:
> > > > >>>>>>>>
> > > > >>>>>>>> I prefer to keep short CLANG9 as the tool
> chain name. I
> > > > >>>>>>>> add wiki page
> > > > >>>>>>>>
> > >
> https://github.com/tianocore/tianocore.github.io/wiki/CL
> ANG9-
> > > > >Tools-
> > > > >>>>> Chain
> > > > >>>>>>>> to introduce it.
> > > > >>>>>>>
> > > > >>>>>>> Why should users be expected to go and
> read documentation
> > in
> > > > >order to
> > > > >>>>>>> learn that fundamental and incompatible
> changes to output
> > > > >>>>>>> and
> > > > >debug
> > > > >>>>>>> format has been made as part of what looks
> like a simple
> > > > >>>>>>> version
> > > > >bump?
> > > > >>>>>>>
> > > > >>>>>>>> And, we have CLANG38 tool chain. It
> generates ELF image
> > > > >>>>>>>> and DWARF debug symbol format. It can
> work with LLVM 9.0
> > release.
> > > > >>>>>>>> Current tool chain tag name includes
> compiler name and
> > version.
> > > > >>>>>>>> There is no specific info in the tool
> chain name. The
> > > > >>>>>>>> developer can get the more tool chain
> information from
> > > > >>>>>>>> wiki
> > > page.
> > > > >>>>>>>
> > > > >>>>>>> We aleady have the problem that people
> think they need to
> > > > >>>>>>> use
> > > > >GCC5 to
> > > > >>>>>>> build EDK2 since that is the highest named
> GCC toolchain profile.
> > > > >>>>>>>
> > > > >>>>>>> Let's not make this situation *worse* by
> setting up a
> > > > >multidimensional
> > > > >>>>>>> feature matrix, based off random numerical
> values.
> > > > >>>>>>>
> > > > >>>>>>> So say that we next have a pressing need
> to create a new
> > > > >>>>>>> toolchain profile for clang 10, using the
> old ELF mechanism.
> > > > >>>>>>> Are you then suggesting we set up a table
> on said wiki
> > > > >>>>>>> page where people have to
> > > > >go
> > > > >>>>>>> and look up what the object and debug
> formats are for each
> > > > >CLANG##
> > > > >>>>>>> toolchain profile?
> > > > >>>>>>>
> > > > >>>>>>> And what if you then end up needing to do
> the same for the
> > > > >>>>>>> PDB flavour?
> > > > >>>>>>>
> > > > >>>>>>>> CLANG9 is designed to support Emulator
> for Windows host
> > only.
> > > > >>>>>>>
> > > > >>>>>>> Which is why it makes no sense to name it
> as a successor
> > > > >>>>>>> of CLANG38.
> > > > >>>>>>>
> > > > >>>>>>>> CLANG38 may be used for Emulator in Linux
> or Mac. I don’t
> > > > >>>>>>>> try it before.
> > > > >>>>>>>>
> > > > >>>>>>>> CLANG9 goal is to align the same compiler
> in the
> > > > >>>>>>>> different host development environment.
> It can replace VS
> > > > >>>>>>>> or GCC compiler. On Windows Host, I
> verify VS debugger
> > > > >>>>>>>> for the source
> > > level debug.
> > > > >>>>>>>> On Linux host, I have not verified llvm
> debugger. I will
> > > > >>>>>>>> investigate the debugger solution for
> OVMF in Linux host.
> > > > >>>>>>>
> > > > >>>>>>> We are not asking you to throw out this
> toolchain profile.
> > > > >>>>>>>
> > > > >>>>>>> We are saying that since the functionality
> it provides is
> > > > >>>>>>> completely unrelated to that of CLANG38,
> it should not be
> > > > >>>>>>> named in a way that suggests it is merely
> a revision update.
> > > > >>>>>>>
> > > > >>>>>>> /
> > > > >>>>>>>   Leif
> > > > >>>>>>>
> > > > >>>>>>>> Thanks
> > > > >>>>>>>> Liming
> > > > >>>>>>>> From: afish@apple.com <afish@apple.com>
> > > > >>>>>>>> Sent: Saturday, October 26, 2019 2:45 AM
> > > > >>>>>>>> To: devel@edk2.groups.io; Gao, Liming
> > > > >>>>>>>> <liming.gao@intel.com>
> > > > >>>>>>>> Cc: Ni, Ray <ray.ni@intel.com>; Justen,
> Jordan L
> > > > >>>>> <jordan.l.justen@intel.com>
> > > > >>>>>>>> Subject: Re: [edk2-devel] [Patch v3
> 10/11] EmulatorPkg:
> > > > >>>>>>>> Enable
> > > > >CLANG9
> > > > >>>>> tool chain
> > > > >>>>>>>>
> > > > >>>>>>>> Liming,
> > > > >>>>>>>>
> > > > >>>>>>>> Sorry I missed this mail. Thanks for the
> info! I was
> > > > >>>>>>>> doing some
> > > > >research
> > > > >>>>> into this too and now I think I finally
> understand. I think
> > > > >>>>> the name for
> > > > >the tool
> > > > >>>>> chain really confused me and we should think
> about changing
> > > > >>>>> the
> > > > name.
> > > > >>>>>>>>
> > > > >>>>>>>> From what I understand CLANG9 means
> produce PE/COFF
> > > directly
> > > > >and
> > > > >>>>> used the PDB debugging format. I see from
> the llvm site that
> > > > >>>>> the linker
> > > > >can
> > > > >>>>> produce PDB directly as you mention. This
> all makes sense to
> > > > >>>>> me now as
> > > > >LLVM
> > > > >>>>> tries to make it easy to be a drop in
> replacement for VC++ or GCC.
> > > > >>>>> So
> > > > >this tool
> > > > >>>>> chain is designed to be able to cross build
> a "Windows App"
> > > > >>>>> on a Linux or macOS. It also looks like the
> llvm debugger,
> > > > >>>>> lldb, is lagging in its support
> > > > >for
> > > > >>>>> PDB based debugging.
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> Anyway I think Leif and I agree the
> toolchain name is
> > > > >>>>>>>> very
> > > > confusing.
> > > > >I'd
> > > > >>>>> rather see it called CLANG9_WIN or
> CLANG_PDB.
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> On Oct 18, 2019, at 7:27 AM, Liming Gao
> > > > >>>>>
> <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> wrote:
> > > > >>>>>>>>
> > > > >>>>>>>> Andrew:
> > > > >>>>>>>> Here is the cover letter on CLANG9
> introduction.
> > > > >>>>> https://edk2.groups.io/g/devel/message/49157
> > > > >>>>>>>>
> > > > >>>>>>>> 1)      Yes. CLANG9 tool chain is added
> to directly generate
> > > PE/COFF
> > > > >image
> > > > >>>>> (EFI image).
> > > > >>>>>>>> This tool chain uses LLVM clang C
> compiler and lld
> > > > >>>>>>>> linker, generates
> > > > >>>>> PE/COFF
> > > > >>>>>>>> image and PDB compatible debug symbol
> format. Now, it
> > > > supports
> > > > >>>>> IA32/X64 Archs.
> > > > >>>>>>>> LLVM clang C compiler and lld linker are
> the standalone
> > > > >>>>>>>> tool
> > set.
> > > > >They
> > > > >>>>> don’t depend other lib to generate PE/COFF
> image.
> > > > >>>>>>>>
> > > > >>>>>>>> 2)      Yes. CLANG9 is the cross OS tool
> chain. It can work on
> > > > >>>>> Windows/Linux/Mac host OS.
> > > > >>>>>>>> LLVM LLD linker uses Windows style
> arguments. I verify
> > > > >>>>>>>> CLANG9 for
> > > > >>>>> Ovmf3264 in Windows/Linux host OS.
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> On Linux can you source level debug Ovmf?
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> 3)     This patch enables WinHost in
> Windows. It doesn’t enable
> > > > >UnixHost.
> > > > >>>>> Now, EmulatorPkg with CLANG9 only works on
> Windows Host.
> > > > >>>>>>>> This patch can make other modules pass
> build in
> > > > >Windows/Linux/Mac
> > > > >>>>> only if LLVM9 tool set is installed.
> > > > >>>>>>>> But, the generated image may not work on
> Linux/Mac. I
> > > > >>>>>>>> agree
> > > > >below
> > > > >>>>> linker flags are specific to windows host.
> > > > >>>>>>>> So, I suggest to add the conditional
> statement of
> > > > >$(WIN_HOST_BUILD)
> > > > >>>>> == TRUE for them.
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> For the EmulatorPkg the Host is a native
> App for that OS
> > > > >>>>>>>> you build on,
> > > > >but
> > > > >>>>> it seems like CLANG9 is targeted to build
> Windows Apps. I'm
> > > > >>>>> not sure
> > > > >but you
> > > > >>>>> might be able to override all the linker
> commands to build a
> > > > >>>>> native app,
> > > > >or just
> > > > >>>>> use the system linker for the Host?
> > > > >>>>>>>>
> > > > >>>>>>>> I'm not sure how well debugging will work
> mixing PDB and
> > > > >>>>>>>> DWARF
> > > > >>>>> symbol formats?
> > > > >>>>>>>>
> > > > >>>>>>>> Thanks,
> > > > >>>>>>>>
> > > > >>>>>>>> Andrew Fish
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> !if $(WIN_HOST_BUILD) == TRUE
> > > > >>>>>>>> GCC:*_CLANG9_*_DLINK_FLAGS     =
> /ALIGN:4096
> > > > /FILEALIGN:4096
> > > > >>>>> /SUBSYSTEM:CONSOLE
> > > > >>>>>>>> GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
> > > > >>>>>
> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> /BASE:0x10000
> > > > >>>>>>>> GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
> > > > >>>>>
> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> /BASE:0x10000
> > > > >>>>>>>> !endif
> > > > >>>>>>>>
> > > > >>>>>>>> Thanks
> > > > >>>>>>>> Liming
> > > > >>>>>>>> From:
> afish@apple.com<mailto:afish@apple.com>
> > > > >>>>> <afish@apple.com<mailto:afish@apple.com>>
> > > > >>>>>>>> Sent: Friday, October 18, 2019 1:15 AM
> > > > >>>>>>>> To: Ni, Ray
> <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > > > >>>>>>>> Cc: Gao, Liming
> > > >
> ><liming.gao@intel.com<mailto:liming.gao@intel.com>>;
> > > > >>>>>
> devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> Justen,
> > > > Jordan
> > > > >>>>> L
> > > > >>>>>
> <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.
> com>
> > > > >>>>> >
> > > > >>>>>>>> Subject: Re: [Patch v3 10/11]
> EmulatorPkg: Enable CLANG9
> > > > >>>>>>>> tool chain
> > > > >>>>>>>>
> > > > >>>>>>>> Ray,
> > > > >>>>>>>>
> > > > >>>>>>>> Sorry I'm coming a little late to this
> and I'm confused.
> > > > >>>>>>>> I have some
> > > > >>>>> questions?
> > > > >>>>>>>> 1) Does CLANG9 imply CLANGPE?
> > > > >>>>>>>> 2) Does CLANGPE work on Linux and macOS?
> Can you pass the
> > > > >Windows
> > > > >>>>> style arguments to CLANGPE linker on Linux
> and macOS?
> > > > >>>>>>>> 3) For the EmulatorPkg don't you have the
> extra
> > > > >>>>>>>> requirement that
> > > > >>>>> compiler needs a standard C lib (or platform
> specific libs)
> > > > >>>>> to
> > function?
> > > > >>>>>>>>      a) GCC:*_CLANG9_*_DLINK_FLAGS in
> EmulatorPkg.dsc
> > > seems
> > > > to
> > > > >>>>> imply the Linux and macOS systems will have
> a Windows SKD
> > > > >>>>> dir and a
> > > > >lot of
> > > > >>>>> Windows DLLs? Does all that come when you
> install CLANG9
> > > > >>>>> when
> > > > you
> > > > >install
> > > > >>>>> it on Linux or macOS?
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> So I guess I'm asking is the linker
> really the same for
> > > > >>>>>>>> CLANG9 on all
> > > > >>>>> systems? I guess the answer could be yes,
> but it seems the C
> > > > >>>>> lib for the
> > > > >Host
> > > > >>>>> App is still an App for that OS and is OS
> dependent?
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> Sorry if I'm missing something
> fundamental and this is a
> > > > >>>>>>>> dumb
> > > > >question.
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> Thanks,
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> Andrew Fish
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> On Oct 17, 2019, at 12:27 AM, Ni, Ray
> > > > >>>>> <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> wrote:
> > > > >>>>>>>>
> > > > >>>>>>>> Liming,
> > > > >>>>>>>> Emulator is using a generic SEC module.
> The host specific
> > > > >>>>>>>> module is
> > > > >called
> > > > >>>>> "Host".
> > > > >>>>>>>> So I prefer to change the macro to
> "WIN_HOST_BUILD", with
> > > > >>>>>>>> this
> > > > >change,
> > > > >>>>> Reviewed-by: Ray Ni
> > > > >>>>> <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> -----Original Message-----
> > > > >>>>>>>> From: Gao, Liming
> > > >
> ><liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > >>>>>>>> Sent: Thursday, October 17, 2019 2:56 PM
> > > > >>>>>>>> To:
> devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> > > > >>>>>>>> Cc: Justen, Jordan L
> > > > >>>>>
> <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.
> com>
> > > > >>>>> >;
> > > > >Andrew
> > > > >>>>> Fish
> > > > >>>>>>>>
> <afish@apple.com<mailto:afish@apple.com>>; Ni, Ray
> > > > >>>>> <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > > > >>>>>>>> Subject: [Patch v3 10/11] EmulatorPkg:
> Enable CLANG9 tool
> > > > >>>>>>>> chain
> > > > >>>>>>>>
> > > > >>>>>>>> BZ:
> https://bugzilla.tianocore.org/show_bug.cgi?id=1603
> > > > >>>>>>>> 1. Add WIN_SEC_BUILD macro check for
> CLANG9 tool chain
> > > > >>>>>>>> build
> > > > >>>>>>>> -
> > > > p
> > > > >>>>>>>> EmulatorPkg\EmulatorPkg.dsc -a IA32 -
> > DWIN_SEC_BUILD=TRUE
> > > -t
> > > > >>>>> CLANG9
> > > > >>>>>>>> build -p EmulatorPkg\EmulatorPkg.dsc -a
> X64 -
> > > > >DWIN_SEC_BUILD=TRUE -t
> > > > >>>>>>>> CLANG9 2. Append CLANG CC and LINK flags
> to generate
> > > windows
> > > > >HOST.
> > > > >>>>>>>> 3. Fix WinHost issue to call
> GetProcessAffinityMask() API.
> > > > >>>>>>>> The input parameter should be UINTN
> pointer instead of
> > > UINT32
> > > > >pointer.
> > > > >>>>>>>>
> > > > >>>>>>>> Cc: Jordan Justen
> > > > >>>>>
> <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.
> com>
> > > > >>>>> >
> > > > >>>>>>>> Cc: Andrew Fish
> <afish@apple.com<mailto:afish@apple.com>>
> > > > >>>>>>>> Cc: Ray Ni
> <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > > > >>>>>>>> Signed-off-by: Liming Gao
> > > > >>>>>
> <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > >>>>>>>> ---
> > > > >>>>>>>> EmulatorPkg/Win/Host/WinHost.c   | 6 +++-
> --
> > > > >>>>>>>> EmulatorPkg/EmulatorPkg.dsc      | 7
> ++++++-
> > > > >>>>>>>> EmulatorPkg/Win/Host/WinHost.inf | 6
> ++++++
> > > > >>>>>>>> 3 files changed, 15 insertions(+), 4
> deletions(-)
> > > > >>>>>>>>
> > > > >>>>>>>> diff --git
> a/EmulatorPkg/Win/Host/WinHost.c
> > > > >>>>>>>> b/EmulatorPkg/Win/Host/WinHost.c index
> > > > 9aba3c8959..e40ce32548
> > > > >>>>> 100644
> > > > >>>>>>>> --- a/EmulatorPkg/Win/Host/WinHost.c
> > > > >>>>>>>> +++ b/EmulatorPkg/Win/Host/WinHost.c
> > > > >>>>>>>> @@ -356,7 +356,7 @@ Returns:
> > > > >>>>>>>> INTN
> > > > >>>>>>>> EFIAPI
> > > > >>>>>>>> main (
> > > > >>>>>>>> -  IN  INTN  Argc,
> > > > >>>>>>>> +  IN  INT  Argc,
> > > > >>>>>>>> IN  CHAR8 **Argv,
> > > > >>>>>>>> IN  CHAR8 **Envp
> > > > >>>>>>>> )
> > > > >>>>>>>> @@ -391,8 +391,8 @@ Returns:
> > > > >>>>>>>> VOID                  *SecFile;
> > > > >>>>>>>> CHAR16                *MemorySizeStr;
> > > > >>>>>>>> CHAR16
> *FirmwareVolumesStr;
> > > > >>>>>>>> -  UINT32
> ProcessAffinityMask;
> > > > >>>>>>>> -  UINT32
> SystemAffinityMask;
> > > > >>>>>>>> +  UINTN
> ProcessAffinityMask;
> > > > >>>>>>>> +  UINTN
> SystemAffinityMask;
> > > > >>>>>>>> INT32                 LowBit;
> > > > >>>>>>>>
> > > > >>>>>>>> //
> > > > >>>>>>>> diff --git a/EmulatorPkg/EmulatorPkg.dsc
> > > > >>>>> b/EmulatorPkg/EmulatorPkg.dsc
> > > > >>>>>>>> index 20f1187713..72532f5daf 100644
> > > > >>>>>>>> --- a/EmulatorPkg/EmulatorPkg.dsc
> > > > >>>>>>>> +++ b/EmulatorPkg/EmulatorPkg.dsc
> > > > >>>>>>>> @@ -237,9 +237,10 @@
> > > > >>>>>>>>
> > > > >>>>>>>> [Components]
> > > > >>>>>>>> !if "IA32" in $(ARCH) || "X64" in $(ARCH)
> > > > >>>>>>>> -  !if "MSFT" in $(FAMILY)
> > > > >>>>>>>> +  !if "MSFT" in $(FAMILY) ||
> $(WIN_SEC_BUILD) == TRUE
> > > > >>>>>>>>   ##
> > > > >>>>>>>>   #  Emulator, OS WIN application
> > > > >>>>>>>> +    #  CLANG9 is cross OS tool chain. It
> depends on
> > > > >>>>>>>> + WIN_SEC_BUILD
> > > > >>>>> macro.
> > > > >>>>>>>>   ##
> > > > >>>>>>>>   EmulatorPkg/Win/Host/WinHost.inf !else
> @@ -419,7
> > > > >>>>>>>> +420,11
> > > > @@
> > > > >>>>>>>>
> > > > >>>>>>>> MSFT:DEBUG_*_*_CC_FLAGS = /Od /Oy-
> > > > MSFT:NOOPT_*_*_CC_FLAGS =
> > > > >>>>>>>> /Od /Oy-
> > > > >>>>>>>> +  GCC:DEBUG_CLANG9_*_CC_FLAGS =-O0 -Wno-
> unused-
> > > > >command-
> > > > >>>>> line-
> > > > >>>>>>>> argument
> > > > >>>>>>>> + -Wno-incompatible-pointer-types -Wno-
> enum-conversion
> > > > >>>>>>>> + -Wno-incompatible-pointer-types -Wno-
> sometimes-
> > > > uninitialized
> > > > >>>>>>>> + -Wno-constant-conversion -Wno-main-
> return-type
> > > > >>>>>>>>
> > > > >>>>>>>> MSFT:*_*_*_DLINK_FLAGS     = /ALIGN:4096
> /FILEALIGN:4096
> > > > >>>>>>>> /SUBSYSTEM:CONSOLE
> > > > >>>>>>>> MSFT:DEBUG_*_*_DLINK_FLAGS =
> > > > >>>>>>>>
> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> > > /BASE:0x10000
> > > > >>>>>>>> MSFT:NOOPT_*_*_DLINK_FLAGS =
> > > > >>>>>>>>
> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> > > /BASE:0x10000
> > > > >>>>>>>> +  GCC:*_CLANG9_*_DLINK_FLAGS     =
> /ALIGN:4096
> > > > >/FILEALIGN:4096
> > > > >>>>>>>> /SUBSYSTEM:CONSOLE
> > > > >>>>>>>> +  GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
> > > > >>>>>>>> +
> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> > > > /BASE:0x10000
> > > > >>>>>>>> + GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
> > > > >>>>>>>> +
> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> > > > /BASE:0x10000
> > > > >>>>>>>> diff --git
> a/EmulatorPkg/Win/Host/WinHost.inf
> > > > >>>>>>>> b/EmulatorPkg/Win/Host/WinHost.inf
> > > > >>>>>>>> index 631d5a6470..1adca10d79 100644
> > > > >>>>>>>> --- a/EmulatorPkg/Win/Host/WinHost.inf
> > > > >>>>>>>> +++ b/EmulatorPkg/Win/Host/WinHost.inf
> > > > >>>>>>>> @@ -95,3 +95,9 @@
> > > > >>>>>>>> MSFT:*_VS2017_X64_DLINK_FLAGS      =
> > > > >>>>>>>> /LIBPATH:"%VCToolsInstallDir%lib\x64"
> > > > >>>>>>>>
> > >
> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64
> "
> > > > >>>>>>>>
> > > >
> >/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\
> x64"
> > > > >>>>>>>> /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB
> > > /IGNORE:4086
> > > > >/MAP
> > > > >>>>>>>> /OPT:REF /DEBUG /MACHINE:AMD64 /LTCG
> Kernel32.lib
> > > > >MSVCRTD.lib
> > > > >>>>>>>> vcruntimed.lib ucrtd.lib Gdi32.lib
> User32.lib Winmm.lib
> > > > Advapi32.lib
> > > > >>>>>>>> MSFT:*_*_X64_ASM_FLAGS            ==
> /nologo /W3 /WX /c /Cx
> > > /Zd
> > > > >/W0
> > > > >>>>> /Zi
> > > > >>>>>>>> MSFT:*_*_X64_ASMLINK_FLAGS        ==
> /link /nologo
> > > > >>>>>>>> +
> > > > >>>>>>>> +  GCC:*_CLANG9_X64_DLINK_FLAGS ==
> > > > >>>>>>>> /out:"$(BIN_DIR)\$(BASE_NAME).exe"
> /base:0x10000000
> > > > >>>>>>>> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> > > > >>>>>>>>
> > >
> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64
> "
> > > > >>>>>>>>
> > > >
> >/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\
> x64"
> > > > >>>>>>>> /LIBPATH:"%VCToolsInstallDir%lib\x64"
> /NOLOGO
> > > > >>>>> /SUBSYSTEM:CONSOLE
> > > > >>>>>>>> /NODEFAULTLIB /IGNORE:4086  /OPT:REF
> /DEBUG
> > > > >/MACHINE:AMD64
> > > > >>>>>>>> Kernel32.lib MSVCRTD.lib vcruntimed.lib
> ucrtd.lib
> > > > >>>>>>>> Gdi32.lib
> > > > >User32.lib
> > > > >>>>>>>> Winmm.lib Advapi32.lib /lldmap
> > > > >>>>>>>>
> /EXPORT:InitializeDriver=_ModuleEntryPoint
> > > > >>>>>>>> +  GCC:*_CLANG9_X64_CC_FLAGS == -m64 -g -
> fshort-wchar
> > > > >>>>>>>> + -fno-strict-aliasing -Wall -c -include
> AutoGen.h -D
> > > > >>>>>>>> + _CRT_SECURE_NO_WARNINGS -Wnonportable-
> include-
> > path
> > > -D
> > > > >>>>> UNICODE
> > > > >>>>>>>> -D
> > > > >>>>>>>> + _CRT_SECURE_NO_DEPRECATE
> > > > >>>>>>>> +
> > > > >>>>>>>> +  GCC:*_CLANG9_IA32_DLINK_FLAGS ==
> > > > >>>>>>>> /out:"$(BIN_DIR)\$(BASE_NAME).exe"
> /base:0x10000000
> > > > >>>>>>>> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> > > > >>>>>>>>
> > >
> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86
> "
> > > > >>>>>>>>
> > > >
> >/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\
> x86"
> > > > >>>>>>>> /LIBPATH:"%VCToolsInstallDir%ib\x86"
> /NOLOGO
> > > > >>>>> /SUBSYSTEM:CONSOLE
> > > > >>>>>>>> /NODEFAULTLIB /IGNORE:4086  /OPT:REF
> /DEBUG
> > > /MACHINE:I386
> > > > >>>>>>>> Kernel32.lib MSVCRTD.lib vcruntimed.lib
> ucrtd.lib
> > > > >>>>>>>> Gdi32.lib
> > > > >User32.lib
> > > > >>>>>>>> Winmm.lib Advapi32.lib /lldmap
> > > > >>>>>>>>
> /EXPORT:InitializeDriver=_ModuleEntryPoint
> > > > >>>>>>>> +  GCC:*_CLANG9_IA32_CC_FLAGS == -m32 -g
> -fshort-wchar
> > > > >>>>>>>> + -fno-strict-aliasing -Wall -c -include
> AutoGen.h -D
> > > > >>>>>>>> + _CRT_SECURE_NO_WARNINGS -Wnonportable-
> include-
> > path
> > > -D
> > > > >>>>> UNICODE
> > > > >>>>>>>> -D
> > > > >>>>>>>> + _CRT_SECURE_NO_DEPRECATE
> > > > >>>>>>>> --
> > > > >>>>>>>> 2.13.0.windows.1
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>
> > > > >
> > > > >
> > >
> > >
> > >
> >
> >
> >
> 
> 
> 

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

[Ni, Ray]

Mike,
I did a simple research in the web and found the slides: 
https://llvm.org/devmtg/2016-11/Slides/Kleckner-CodeViewInLLVM.pdf

In page #3, it says:
"CodeView is stored inside object files and PDBs"
"PDB is a container format written by linker and read by debugger"

The relationships between terms are:
"CodeView :: DWARF"
"PDB :: dSYM"
"PDB :: DWP"


I also found information from "https://llvm.org/docs/PDB/index.html":
"CodeView is another format which comes into the picture. While MSF
defines the structure of the overall file, and PDB defines the set of streams
that appear within the MSF file and the format of those streams, CodeView
defines the format of symbol and type records that appear within specific
streams."

With all these information, I am ok with any of CLANGCODEVIEW, CLANGCV or CLANGPDB.

Developers who care about symbolic debugging should be aware of what kind of
debug symbol is generated by build.

Thanks,
Ray

> -----Original Message-----
> From: Kinney, Michael D <michael.d.kinney@intel.com>
> Sent: Tuesday, November 12, 2019 11:48 AM
> To: devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com>; Gao, Liming
> <liming.gao@intel.com>; afish@apple.com; Leif Lindholm
> <leif.lindholm@linaro.org>; Kinney, Michael D <michael.d.kinney@intel.com>
> Cc: Justen, Jordan L <jordan.l.justen@intel.com>; Shi, Steven
> <steven.shi@intel.com>
> Subject: RE: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool
> chain
> 
> Ray,
> 
> I agree that a name that represents the symbolic debug format makes more
> sense.
> 
> The term 'PE' is short for PE/COFF, and that is the required final output
> format.  A toolchain profile that happens to go through other intermediate
> formats (e.g.
> elf or macho) before finally generating a PE/COFF image is usually not that
> interesting to most developers.  So adding 'PE' to the name is redundant
> information.
> 
> The attribute of the images that does impact developers is the format of the
> symbol information.  Even for Visual Studio, PDB is the file extension used
> when the symbol information is placed in a separate file.  The Visual Studio
> compilers do support putting the symbol information in a section of the
> PE/COFF image.  EDK II builds happen to always use the PDB option to
> minimize the size of firmware images. So PDB may not be the right name
> either.  I think the symbol format in the PDB that is used is codeview.
> 
> If we want to plan ahead for toolchain names perhaps:
> 
> Codeview: CLANGCODEVIEW or CLANGCV or CLANGPDB
> Dwarf:    CLANGDWARF
> 
> Best regards,
> 
> Mike
> 
> > -----Original Message-----
> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Ni,
> Ray
> > Sent: Monday, November 11, 2019 7:23 PM
> > To: devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com>; Gao, Liming
> > <liming.gao@intel.com>; afish@apple.com; Leif Lindholm
> > <leif.lindholm@linaro.org>
> > Cc: Justen, Jordan L <jordan.l.justen@intel.com>; Shi, Steven
> > <steven.shi@intel.com>
> > Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg:
> > Enable CLANG9 tool chain
> >
> > And LLVM I believe is capable to support generating PE + DWARF.
> > That's my second concern: Using CLANGPE may not imply PDB is used from
> > a LLVM expert's understanding.
> >
> >
> > > -----Original Message-----
> > > From: devel@edk2.groups.io <devel@edk2.groups.io> On
> > Behalf Of Ni, Ray
> > > Sent: Tuesday, November 12, 2019 11:10 AM
> > > To: devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com>;
> > Gao, Liming
> > > <liming.gao@intel.com>; afish@apple.com; Leif Lindholm
> > > <leif.lindholm@linaro.org>
> > > Cc: Justen, Jordan L <jordan.l.justen@intel.com>; Shi,
> > Steven
> > > <steven.shi@intel.com>
> > > Subject: Re: [edk2-devel] [Patch v3 10/11]
> > EmulatorPkg: Enable CLANG9
> > > tool chain
> > >
> > > My point is if we choose CLANGPE, for LLVM toolchain
> > supporting DWARF
> > > debug symbol, there is no proper name left: we cannot
> > use CLANGELF.
> > >
> > > Andrew, you said CLANGPDE. A typo?
> > >
> > > > -----Original Message-----
> > > > From: devel@edk2.groups.io <devel@edk2.groups.io> On
> > Behalf Of Ni,
> > > Ray
> > > > Sent: Tuesday, November 12, 2019 9:46 AM
> > > > To: Gao, Liming <liming.gao@intel.com>;
> > devel@edk2.groups.io;
> > > > afish@apple.com; Leif Lindholm
> > <leif.lindholm@linaro.org>
> > > > Cc: Justen, Jordan L <jordan.l.justen@intel.com>;
> > Shi, Steven
> > > > <steven.shi@intel.com>
> > > > Subject: Re: [edk2-devel] [Patch v3 10/11]
> > EmulatorPkg: Enable
> > > > CLANG9 tool chain
> > > >
> > > > Liming,
> > > > What name will be chosen when in future someone
> > wants a LLVM
> > > toolchain
> > > > which supports DWARF debug symbol?
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Gao, Liming <liming.gao@intel.com>
> > > > > Sent: Tuesday, November 12, 2019 8:41 AM
> > > > > To: devel@edk2.groups.io; afish@apple.com; Leif
> > Lindholm
> > > > > <leif.lindholm@linaro.org>
> > > > > Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L
> > > > > <jordan.l.justen@intel.com>; Shi, Steven
> > <steven.shi@intel.com>;
> > > > > Gao, Liming <liming.gao@intel.com>
> > > > > Subject: RE: [edk2-devel] [Patch v3 10/11]
> > EmulatorPkg: Enable
> > > > > CLANG9 tool chain
> > > > >
> > > > > Thanks for your feedback. I will choose CLANGPE as
> > the tool chain name.
> > > > >
> > > > > Thanks
> > > > > Liming
> > > > > >-----Original Message-----
> > > > > >From: devel@edk2.groups.io
> > [mailto:devel@edk2.groups.io] On
> > > > > >Behalf Of Andrew Fish via Groups.Io
> > > > > >Sent: Tuesday, November 12, 2019 12:52 AM
> > > > > >To: Leif Lindholm <leif.lindholm@linaro.org>
> > > > > >Cc: Ni, Ray <ray.ni@intel.com>; Gao, Liming
> > > > > ><liming.gao@intel.com>; devel@edk2.groups.io;
> > Justen, Jordan L
> > > > > ><jordan.l.justen@intel.com>; Shi, Steven
> > <steven.shi@intel.com>
> > > > > >Subject: Re: [edk2-devel] [Patch v3 10/11]
> > EmulatorPkg: Enable
> > > > > >CLANG9 tool chain
> > > > > >
> > > > > >Either works for me too. I like the PDE ending a
> > little more, but
> > > > > >agree it is a little more obscure.
> > > > > >> On Nov 11, 2019, at 8:39 AM, Leif Lindholm
> > > > > >> <leif.lindholm@linaro.org>
> > > > > wrote:
> > > > > >>
> > > > > >> On Fri, Nov 08, 2019 at 03:34:59AM +0000, Ni,
> > Ray wrote:
> > > > > >>> Liming,
> > > > > >>> PE is UEFI spec required executable binary
> > format. I like
> > > > > >>> CLANGPDB more than CLANGPE given LLVM may
> > generate DRAWF
> > > debug
> > > > > >>> symbol
> > > > > >even
> > > > > >>> when generating PE.
> > > > > >>
> > > > > >> Just a comment here to point out that while (as
> > I stated in
> > > > > >> reply to
> > > > > >> Liming) my preference would be CLANGPE, I see
> > the logic in the
> > > > > >> above, and would be happy with either.
> > > > > >>
> > > > > >> (My reason for preferring CLANGPE is not
> > exactly techincal - I
> > > > > >> just expect more people to know what PE is than
> > who know what
> > > > > >> PDB
> > > > > >> is.)
> > > > > >>
> > > > > >> Regards,
> > > > > >>
> > > > > >> Leif
> > > > > >>
> > > > > >>>> -----Original Message-----
> > > > > >>>> From: Gao, Liming <liming.gao@intel.com>
> > > > > >>>> Sent: Friday, November 8, 2019 9:50 AM
> > > > > >>>> To: devel@edk2.groups.io;
> > leif.lindholm@linaro.org; Andrew
> > > > > >>>> Fish
> > > > > ><afish@apple.com>
> > > > > >>>> Cc: Ni, Ray <ray.ni@intel.com>; Justen,
> > Jordan L
> > > > > ><jordan.l.justen@intel.com>; Gao, Liming
> > <liming.gao@intel.com>;
> > > > > >Shi,
> > > > > >>>> Steven <steven.shi@intel.com>
> > > > > >>>> Subject: RE: [edk2-devel] [Patch v3 10/11]
> > EmulatorPkg:
> > > > > >>>> Enable
> > > > > >>>> CLANG9
> > > > > >tool chain
> > > > > >>>>
> > > > > >>>> Andrew and Leif:
> > > > > >>>>  Thanks for your comment. CLANG9 is different
> > from CLANG38.
> > > > > >>>> And,
> > > > > >CLANG9 will support LLVM9 or the above.
> > > > > >>>>  So, this tool chain should have the specific
> > word for its
> > > > > >>>> purpose, and
> > > > > >remove the version 9 to avoid the confuse.
> > > > > >>>>
> > > > > >>>>  I prefer the tool chain name as CLANGPE or
> > CLANGPDB. CLANGPE
> > > > may
> > > > > >be better. Now, CLANG9 tool chain
> > > > > >>>>  build rule family just uses CLANGPE. CLANGPE
> > lets user know
> > > > > >>>> this tool
> > > > > >chain generates PE/COFF image.
> > > > > >>>>  And, PE/COFF image debug symbol is PDB. So,
> > PE also means PDB.
> > > > > >>>>
> > > > > >>>>  Last, I just review the changes. Tool chain
> > name update is
> > > > > >>>> not big. If you
> > > > > >accept CLANGPE as tool chain name,
> > > > > >>>>  I will send the patch soon to catch 201911
> > stable tag.
> > > > > >>>>
> > > > > >>>> Thanks
> > > > > >>>> Liming
> > > > > >>>>> -----Original Message-----
> > > > > >>>>> From: devel@edk2.groups.io
> > [mailto:devel@edk2.groups.io] On
> > > > > Behalf
> > > > > >Of Leif
> > > > > >>>>> Lindholm
> > > > > >>>>> Sent: Friday, November 08, 2019 2:37 AM
> > > > > >>>>> To: Andrew Fish <afish@apple.com>
> > > > > >>>>> Cc: devel@edk2.groups.io; Gao, Liming
> > > > > >>>>> <liming.gao@intel.com>; Ni, Ray
> > <ray.ni@intel.com>; Justen,
> > > > > >>>>> Jordan L <jordan.l.justen@intel.com>
> > > > > >>>>> Subject: Re: [edk2-devel] [Patch v3 10/11]
> > EmulatorPkg:
> > > > > >>>>> Enable
> > > > > >>>>> CLANG9
> > > > > >tool
> > > > > >>>>> chain
> > > > > >>>>>
> > > > > >>>>> Hi Andrew,
> > > > > >>>>>
> > > > > >>>>> Yeah, I'm pretty easy with regards to what
> > we change it to.
> > > > > >>>>> Although if we're bikeshedding, I would
> > prefer not using _
> > > > > >>>>> in the toolchain profile name.
> > > > > >>>>>
> > > > > >>>>> I'm ... optimistic ... it won't break any of
> > my existing
> > > > > >>>>> scripts, but since the build system uses it
> > as a <toolchain
> > > > > >>>>> profile>_<architecture>_<build target>
> > separator, it would
> > > > > >>>>> profile>be nice
> > > > > >>>>> if we didn't risk confusion there.
> > > > > >>>>>
> > > > > >>>>> (I would be totally happy with PECLANG,
> > CLANGPE, PDBCLANG,
> > > > > >CLANGPDB or
> > > > > >>>>> something along those lines.)
> > > > > >>>>>
> > > > > >>>>> Regards,
> > > > > >>>>>
> > > > > >>>>> Leif
> > > > > >>>>>
> > > > > >>>>> On Thu, Nov 07, 2019 at 11:54:04AM -0600,
> > Andrew Fish wrote:
> > > > > >>>>>> Leif,
> > > > > >>>>>>
> > > > > >>>>>> I think I proposed CLANG_PDB or
> > CLANG_PECOFF. I seem to
> > > > > >>>>>> like
> > > > > >>>>> CLANG_PDB as assuming the PDE debugging
> > experience is
> > > > > >awesome/exists
> > > > > >>>>> on Linux and macOS is not a given.
> > > > > >>>>>>
> > > > > >>>>>> Thanks,
> > > > > >>>>>>
> > > > > >>>>>> Andrew Fish
> > > > > >>>>>>
> > > > > >>>>>>> On Nov 7, 2019, at 11:19 AM, Leif Lindholm
> > > > > >>>>>>> <leif.lindholm@linaro.org>
> > > > > >>>>> wrote:
> > > > > >>>>>>>
> > > > > >>>>>>> Oops, sorry, missed this in search.
> > > > > >>>>>>>
> > > > > >>>>>>> On Wed, Oct 30, 2019 at 03:43:44PM +0000,
> > Liming Gao wrote:
> > > > > >>>>>>>> Andrew:
> > > > > >>>>>>>>
> > > > > >>>>>>>> I prefer to keep short CLANG9 as the tool
> > chain name. I
> > > > > >>>>>>>> add wiki page
> > > > > >>>>>>>>
> > > >
> > https://github.com/tianocore/tianocore.github.io/wiki/CL
> > ANG9-
> > > > > >Tools-
> > > > > >>>>> Chain
> > > > > >>>>>>>> to introduce it.
> > > > > >>>>>>>
> > > > > >>>>>>> Why should users be expected to go and
> > read documentation
> > > in
> > > > > >order to
> > > > > >>>>>>> learn that fundamental and incompatible
> > changes to output
> > > > > >>>>>>> and
> > > > > >debug
> > > > > >>>>>>> format has been made as part of what looks
> > like a simple
> > > > > >>>>>>> version
> > > > > >bump?
> > > > > >>>>>>>
> > > > > >>>>>>>> And, we have CLANG38 tool chain. It
> > generates ELF image
> > > > > >>>>>>>> and DWARF debug symbol format. It can
> > work with LLVM 9.0
> > > release.
> > > > > >>>>>>>> Current tool chain tag name includes
> > compiler name and
> > > version.
> > > > > >>>>>>>> There is no specific info in the tool
> > chain name. The
> > > > > >>>>>>>> developer can get the more tool chain
> > information from
> > > > > >>>>>>>> wiki
> > > > page.
> > > > > >>>>>>>
> > > > > >>>>>>> We aleady have the problem that people
> > think they need to
> > > > > >>>>>>> use
> > > > > >GCC5 to
> > > > > >>>>>>> build EDK2 since that is the highest named
> > GCC toolchain profile.
> > > > > >>>>>>>
> > > > > >>>>>>> Let's not make this situation *worse* by
> > setting up a
> > > > > >multidimensional
> > > > > >>>>>>> feature matrix, based off random numerical
> > values.
> > > > > >>>>>>>
> > > > > >>>>>>> So say that we next have a pressing need
> > to create a new
> > > > > >>>>>>> toolchain profile for clang 10, using the
> > old ELF mechanism.
> > > > > >>>>>>> Are you then suggesting we set up a table
> > on said wiki
> > > > > >>>>>>> page where people have to
> > > > > >go
> > > > > >>>>>>> and look up what the object and debug
> > formats are for each
> > > > > >CLANG##
> > > > > >>>>>>> toolchain profile?
> > > > > >>>>>>>
> > > > > >>>>>>> And what if you then end up needing to do
> > the same for the
> > > > > >>>>>>> PDB flavour?
> > > > > >>>>>>>
> > > > > >>>>>>>> CLANG9 is designed to support Emulator
> > for Windows host
> > > only.
> > > > > >>>>>>>
> > > > > >>>>>>> Which is why it makes no sense to name it
> > as a successor
> > > > > >>>>>>> of CLANG38.
> > > > > >>>>>>>
> > > > > >>>>>>>> CLANG38 may be used for Emulator in Linux
> > or Mac. I don’t
> > > > > >>>>>>>> try it before.
> > > > > >>>>>>>>
> > > > > >>>>>>>> CLANG9 goal is to align the same compiler
> > in the
> > > > > >>>>>>>> different host development environment.
> > It can replace VS
> > > > > >>>>>>>> or GCC compiler. On Windows Host, I
> > verify VS debugger
> > > > > >>>>>>>> for the source
> > > > level debug.
> > > > > >>>>>>>> On Linux host, I have not verified llvm
> > debugger. I will
> > > > > >>>>>>>> investigate the debugger solution for
> > OVMF in Linux host.
> > > > > >>>>>>>
> > > > > >>>>>>> We are not asking you to throw out this
> > toolchain profile.
> > > > > >>>>>>>
> > > > > >>>>>>> We are saying that since the functionality
> > it provides is
> > > > > >>>>>>> completely unrelated to that of CLANG38,
> > it should not be
> > > > > >>>>>>> named in a way that suggests it is merely
> > a revision update.
> > > > > >>>>>>>
> > > > > >>>>>>> /
> > > > > >>>>>>>   Leif
> > > > > >>>>>>>
> > > > > >>>>>>>> Thanks
> > > > > >>>>>>>> Liming
> > > > > >>>>>>>> From: afish@apple.com <afish@apple.com>
> > > > > >>>>>>>> Sent: Saturday, October 26, 2019 2:45 AM
> > > > > >>>>>>>> To: devel@edk2.groups.io; Gao, Liming
> > > > > >>>>>>>> <liming.gao@intel.com>
> > > > > >>>>>>>> Cc: Ni, Ray <ray.ni@intel.com>; Justen,
> > Jordan L
> > > > > >>>>> <jordan.l.justen@intel.com>
> > > > > >>>>>>>> Subject: Re: [edk2-devel] [Patch v3
> > 10/11] EmulatorPkg:
> > > > > >>>>>>>> Enable
> > > > > >CLANG9
> > > > > >>>>> tool chain
> > > > > >>>>>>>>
> > > > > >>>>>>>> Liming,
> > > > > >>>>>>>>
> > > > > >>>>>>>> Sorry I missed this mail. Thanks for the
> > info! I was
> > > > > >>>>>>>> doing some
> > > > > >research
> > > > > >>>>> into this too and now I think I finally
> > understand. I think
> > > > > >>>>> the name for
> > > > > >the tool
> > > > > >>>>> chain really confused me and we should think
> > about changing
> > > > > >>>>> the
> > > > > name.
> > > > > >>>>>>>>
> > > > > >>>>>>>> From what I understand CLANG9 means
> > produce PE/COFF
> > > > directly
> > > > > >and
> > > > > >>>>> used the PDB debugging format. I see from
> > the llvm site that
> > > > > >>>>> the linker
> > > > > >can
> > > > > >>>>> produce PDB directly as you mention. This
> > all makes sense to
> > > > > >>>>> me now as
> > > > > >LLVM
> > > > > >>>>> tries to make it easy to be a drop in
> > replacement for VC++ or GCC.
> > > > > >>>>> So
> > > > > >this tool
> > > > > >>>>> chain is designed to be able to cross build
> > a "Windows App"
> > > > > >>>>> on a Linux or macOS. It also looks like the
> > llvm debugger,
> > > > > >>>>> lldb, is lagging in its support
> > > > > >for
> > > > > >>>>> PDB based debugging.
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>> Anyway I think Leif and I agree the
> > toolchain name is
> > > > > >>>>>>>> very
> > > > > confusing.
> > > > > >I'd
> > > > > >>>>> rather see it called CLANG9_WIN or
> > CLANG_PDB.
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>> On Oct 18, 2019, at 7:27 AM, Liming Gao
> > > > > >>>>>
> > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > wrote:
> > > > > >>>>>>>>
> > > > > >>>>>>>> Andrew:
> > > > > >>>>>>>> Here is the cover letter on CLANG9
> > introduction.
> > > > > >>>>> https://edk2.groups.io/g/devel/message/49157
> > > > > >>>>>>>>
> > > > > >>>>>>>> 1)      Yes. CLANG9 tool chain is added
> > to directly generate
> > > > PE/COFF
> > > > > >image
> > > > > >>>>> (EFI image).
> > > > > >>>>>>>> This tool chain uses LLVM clang C
> > compiler and lld
> > > > > >>>>>>>> linker, generates
> > > > > >>>>> PE/COFF
> > > > > >>>>>>>> image and PDB compatible debug symbol
> > format. Now, it
> > > > > supports
> > > > > >>>>> IA32/X64 Archs.
> > > > > >>>>>>>> LLVM clang C compiler and lld linker are
> > the standalone
> > > > > >>>>>>>> tool
> > > set.
> > > > > >They
> > > > > >>>>> don’t depend other lib to generate PE/COFF
> > image.
> > > > > >>>>>>>>
> > > > > >>>>>>>> 2)      Yes. CLANG9 is the cross OS tool
> > chain. It can work on
> > > > > >>>>> Windows/Linux/Mac host OS.
> > > > > >>>>>>>> LLVM LLD linker uses Windows style
> > arguments. I verify
> > > > > >>>>>>>> CLANG9 for
> > > > > >>>>> Ovmf3264 in Windows/Linux host OS.
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>> On Linux can you source level debug Ovmf?
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>> 3)     This patch enables WinHost in
> > Windows. It doesn’t enable
> > > > > >UnixHost.
> > > > > >>>>> Now, EmulatorPkg with CLANG9 only works on
> > Windows Host.
> > > > > >>>>>>>> This patch can make other modules pass
> > build in
> > > > > >Windows/Linux/Mac
> > > > > >>>>> only if LLVM9 tool set is installed.
> > > > > >>>>>>>> But, the generated image may not work on
> > Linux/Mac. I
> > > > > >>>>>>>> agree
> > > > > >below
> > > > > >>>>> linker flags are specific to windows host.
> > > > > >>>>>>>> So, I suggest to add the conditional
> > statement of
> > > > > >$(WIN_HOST_BUILD)
> > > > > >>>>> == TRUE for them.
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>> For the EmulatorPkg the Host is a native
> > App for that OS
> > > > > >>>>>>>> you build on,
> > > > > >but
> > > > > >>>>> it seems like CLANG9 is targeted to build
> > Windows Apps. I'm
> > > > > >>>>> not sure
> > > > > >but you
> > > > > >>>>> might be able to override all the linker
> > commands to build a
> > > > > >>>>> native app,
> > > > > >or just
> > > > > >>>>> use the system linker for the Host?
> > > > > >>>>>>>>
> > > > > >>>>>>>> I'm not sure how well debugging will work
> > mixing PDB and
> > > > > >>>>>>>> DWARF
> > > > > >>>>> symbol formats?
> > > > > >>>>>>>>
> > > > > >>>>>>>> Thanks,
> > > > > >>>>>>>>
> > > > > >>>>>>>> Andrew Fish
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>> !if $(WIN_HOST_BUILD) == TRUE
> > > > > >>>>>>>> GCC:*_CLANG9_*_DLINK_FLAGS     =
> > /ALIGN:4096
> > > > > /FILEALIGN:4096
> > > > > >>>>> /SUBSYSTEM:CONSOLE
> > > > > >>>>>>>> GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
> > > > > >>>>>
> > /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> > /BASE:0x10000
> > > > > >>>>>>>> GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
> > > > > >>>>>
> > /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> > /BASE:0x10000
> > > > > >>>>>>>> !endif
> > > > > >>>>>>>>
> > > > > >>>>>>>> Thanks
> > > > > >>>>>>>> Liming
> > > > > >>>>>>>> From:
> > afish@apple.com<mailto:afish@apple.com>
> > > > > >>>>> <afish@apple.com<mailto:afish@apple.com>>
> > > > > >>>>>>>> Sent: Friday, October 18, 2019 1:15 AM
> > > > > >>>>>>>> To: Ni, Ray
> > <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > > > > >>>>>>>> Cc: Gao, Liming
> > > > >
> > ><liming.gao@intel.com<mailto:liming.gao@intel.com>>;
> > > > > >>>>>
> > devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> > Justen,
> > > > > Jordan
> > > > > >>>>> L
> > > > > >>>>>
> > <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.
> > com>
> > > > > >>>>> >
> > > > > >>>>>>>> Subject: Re: [Patch v3 10/11]
> > EmulatorPkg: Enable CLANG9
> > > > > >>>>>>>> tool chain
> > > > > >>>>>>>>
> > > > > >>>>>>>> Ray,
> > > > > >>>>>>>>
> > > > > >>>>>>>> Sorry I'm coming a little late to this
> > and I'm confused.
> > > > > >>>>>>>> I have some
> > > > > >>>>> questions?
> > > > > >>>>>>>> 1) Does CLANG9 imply CLANGPE?
> > > > > >>>>>>>> 2) Does CLANGPE work on Linux and macOS?
> > Can you pass the
> > > > > >Windows
> > > > > >>>>> style arguments to CLANGPE linker on Linux
> > and macOS?
> > > > > >>>>>>>> 3) For the EmulatorPkg don't you have the
> > extra
> > > > > >>>>>>>> requirement that
> > > > > >>>>> compiler needs a standard C lib (or platform
> > specific libs)
> > > > > >>>>> to
> > > function?
> > > > > >>>>>>>>      a) GCC:*_CLANG9_*_DLINK_FLAGS in
> > EmulatorPkg.dsc
> > > > seems
> > > > > to
> > > > > >>>>> imply the Linux and macOS systems will have
> > a Windows SKD
> > > > > >>>>> dir and a
> > > > > >lot of
> > > > > >>>>> Windows DLLs? Does all that come when you
> > install CLANG9
> > > > > >>>>> when
> > > > > you
> > > > > >install
> > > > > >>>>> it on Linux or macOS?
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>> So I guess I'm asking is the linker
> > really the same for
> > > > > >>>>>>>> CLANG9 on all
> > > > > >>>>> systems? I guess the answer could be yes,
> > but it seems the C
> > > > > >>>>> lib for the
> > > > > >Host
> > > > > >>>>> App is still an App for that OS and is OS
> > dependent?
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>> Sorry if I'm missing something
> > fundamental and this is a
> > > > > >>>>>>>> dumb
> > > > > >question.
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>> Thanks,
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>> Andrew Fish
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>> On Oct 17, 2019, at 12:27 AM, Ni, Ray
> > > > > >>>>> <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > wrote:
> > > > > >>>>>>>>
> > > > > >>>>>>>> Liming,
> > > > > >>>>>>>> Emulator is using a generic SEC module.
> > The host specific
> > > > > >>>>>>>> module is
> > > > > >called
> > > > > >>>>> "Host".
> > > > > >>>>>>>> So I prefer to change the macro to
> > "WIN_HOST_BUILD", with
> > > > > >>>>>>>> this
> > > > > >change,
> > > > > >>>>> Reviewed-by: Ray Ni
> > > > > >>>>> <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>> -----Original Message-----
> > > > > >>>>>>>> From: Gao, Liming
> > > > >
> > ><liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > >>>>>>>> Sent: Thursday, October 17, 2019 2:56 PM
> > > > > >>>>>>>> To:
> > devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> > > > > >>>>>>>> Cc: Justen, Jordan L
> > > > > >>>>>
> > <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.
> > com>
> > > > > >>>>> >;
> > > > > >Andrew
> > > > > >>>>> Fish
> > > > > >>>>>>>>
> > <afish@apple.com<mailto:afish@apple.com>>; Ni, Ray
> > > > > >>>>> <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > > > > >>>>>>>> Subject: [Patch v3 10/11] EmulatorPkg:
> > Enable CLANG9 tool
> > > > > >>>>>>>> chain
> > > > > >>>>>>>>
> > > > > >>>>>>>> BZ:
> > https://bugzilla.tianocore.org/show_bug.cgi?id=1603
> > > > > >>>>>>>> 1. Add WIN_SEC_BUILD macro check for
> > CLANG9 tool chain
> > > > > >>>>>>>> build
> > > > > >>>>>>>> -
> > > > > p
> > > > > >>>>>>>> EmulatorPkg\EmulatorPkg.dsc -a IA32 -
> > > DWIN_SEC_BUILD=TRUE
> > > > -t
> > > > > >>>>> CLANG9
> > > > > >>>>>>>> build -p EmulatorPkg\EmulatorPkg.dsc -a
> > X64 -
> > > > > >DWIN_SEC_BUILD=TRUE -t
> > > > > >>>>>>>> CLANG9 2. Append CLANG CC and LINK flags
> > to generate
> > > > windows
> > > > > >HOST.
> > > > > >>>>>>>> 3. Fix WinHost issue to call
> > GetProcessAffinityMask() API.
> > > > > >>>>>>>> The input parameter should be UINTN
> > pointer instead of
> > > > UINT32
> > > > > >pointer.
> > > > > >>>>>>>>
> > > > > >>>>>>>> Cc: Jordan Justen
> > > > > >>>>>
> > <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.
> > com>
> > > > > >>>>> >
> > > > > >>>>>>>> Cc: Andrew Fish
> > <afish@apple.com<mailto:afish@apple.com>>
> > > > > >>>>>>>> Cc: Ray Ni
> > <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > > > > >>>>>>>> Signed-off-by: Liming Gao
> > > > > >>>>>
> > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > >>>>>>>> ---
> > > > > >>>>>>>> EmulatorPkg/Win/Host/WinHost.c   | 6 +++-
> > --
> > > > > >>>>>>>> EmulatorPkg/EmulatorPkg.dsc      | 7
> > ++++++-
> > > > > >>>>>>>> EmulatorPkg/Win/Host/WinHost.inf | 6
> > ++++++
> > > > > >>>>>>>> 3 files changed, 15 insertions(+), 4
> > deletions(-)
> > > > > >>>>>>>>
> > > > > >>>>>>>> diff --git
> > a/EmulatorPkg/Win/Host/WinHost.c
> > > > > >>>>>>>> b/EmulatorPkg/Win/Host/WinHost.c index
> > > > > 9aba3c8959..e40ce32548
> > > > > >>>>> 100644
> > > > > >>>>>>>> --- a/EmulatorPkg/Win/Host/WinHost.c
> > > > > >>>>>>>> +++ b/EmulatorPkg/Win/Host/WinHost.c
> > > > > >>>>>>>> @@ -356,7 +356,7 @@ Returns:
> > > > > >>>>>>>> INTN
> > > > > >>>>>>>> EFIAPI
> > > > > >>>>>>>> main (
> > > > > >>>>>>>> -  IN  INTN  Argc,
> > > > > >>>>>>>> +  IN  INT  Argc,
> > > > > >>>>>>>> IN  CHAR8 **Argv,
> > > > > >>>>>>>> IN  CHAR8 **Envp
> > > > > >>>>>>>> )
> > > > > >>>>>>>> @@ -391,8 +391,8 @@ Returns:
> > > > > >>>>>>>> VOID                  *SecFile;
> > > > > >>>>>>>> CHAR16                *MemorySizeStr;
> > > > > >>>>>>>> CHAR16
> > *FirmwareVolumesStr;
> > > > > >>>>>>>> -  UINT32
> > ProcessAffinityMask;
> > > > > >>>>>>>> -  UINT32
> > SystemAffinityMask;
> > > > > >>>>>>>> +  UINTN
> > ProcessAffinityMask;
> > > > > >>>>>>>> +  UINTN
> > SystemAffinityMask;
> > > > > >>>>>>>> INT32                 LowBit;
> > > > > >>>>>>>>
> > > > > >>>>>>>> //
> > > > > >>>>>>>> diff --git a/EmulatorPkg/EmulatorPkg.dsc
> > > > > >>>>> b/EmulatorPkg/EmulatorPkg.dsc
> > > > > >>>>>>>> index 20f1187713..72532f5daf 100644
> > > > > >>>>>>>> --- a/EmulatorPkg/EmulatorPkg.dsc
> > > > > >>>>>>>> +++ b/EmulatorPkg/EmulatorPkg.dsc
> > > > > >>>>>>>> @@ -237,9 +237,10 @@
> > > > > >>>>>>>>
> > > > > >>>>>>>> [Components]
> > > > > >>>>>>>> !if "IA32" in $(ARCH) || "X64" in $(ARCH)
> > > > > >>>>>>>> -  !if "MSFT" in $(FAMILY)
> > > > > >>>>>>>> +  !if "MSFT" in $(FAMILY) ||
> > $(WIN_SEC_BUILD) == TRUE
> > > > > >>>>>>>>   ##
> > > > > >>>>>>>>   #  Emulator, OS WIN application
> > > > > >>>>>>>> +    #  CLANG9 is cross OS tool chain. It
> > depends on
> > > > > >>>>>>>> + WIN_SEC_BUILD
> > > > > >>>>> macro.
> > > > > >>>>>>>>   ##
> > > > > >>>>>>>>   EmulatorPkg/Win/Host/WinHost.inf !else
> > @@ -419,7
> > > > > >>>>>>>> +420,11
> > > > > @@
> > > > > >>>>>>>>
> > > > > >>>>>>>> MSFT:DEBUG_*_*_CC_FLAGS = /Od /Oy-
> > > > > MSFT:NOOPT_*_*_CC_FLAGS =
> > > > > >>>>>>>> /Od /Oy-
> > > > > >>>>>>>> +  GCC:DEBUG_CLANG9_*_CC_FLAGS =-O0 -Wno-
> > unused-
> > > > > >command-
> > > > > >>>>> line-
> > > > > >>>>>>>> argument
> > > > > >>>>>>>> + -Wno-incompatible-pointer-types -Wno-
> > enum-conversion
> > > > > >>>>>>>> + -Wno-incompatible-pointer-types -Wno-
> > sometimes-
> > > > > uninitialized
> > > > > >>>>>>>> + -Wno-constant-conversion -Wno-main-
> > return-type
> > > > > >>>>>>>>
> > > > > >>>>>>>> MSFT:*_*_*_DLINK_FLAGS     = /ALIGN:4096
> > /FILEALIGN:4096
> > > > > >>>>>>>> /SUBSYSTEM:CONSOLE
> > > > > >>>>>>>> MSFT:DEBUG_*_*_DLINK_FLAGS =
> > > > > >>>>>>>>
> > /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> > > > /BASE:0x10000
> > > > > >>>>>>>> MSFT:NOOPT_*_*_DLINK_FLAGS =
> > > > > >>>>>>>>
> > /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> > > > /BASE:0x10000
> > > > > >>>>>>>> +  GCC:*_CLANG9_*_DLINK_FLAGS     =
> > /ALIGN:4096
> > > > > >/FILEALIGN:4096
> > > > > >>>>>>>> /SUBSYSTEM:CONSOLE
> > > > > >>>>>>>> +  GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
> > > > > >>>>>>>> +
> > /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> > > > > /BASE:0x10000
> > > > > >>>>>>>> + GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
> > > > > >>>>>>>> +
> > /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> > > > > /BASE:0x10000
> > > > > >>>>>>>> diff --git
> > a/EmulatorPkg/Win/Host/WinHost.inf
> > > > > >>>>>>>> b/EmulatorPkg/Win/Host/WinHost.inf
> > > > > >>>>>>>> index 631d5a6470..1adca10d79 100644
> > > > > >>>>>>>> --- a/EmulatorPkg/Win/Host/WinHost.inf
> > > > > >>>>>>>> +++ b/EmulatorPkg/Win/Host/WinHost.inf
> > > > > >>>>>>>> @@ -95,3 +95,9 @@
> > > > > >>>>>>>> MSFT:*_VS2017_X64_DLINK_FLAGS      =
> > > > > >>>>>>>> /LIBPATH:"%VCToolsInstallDir%lib\x64"
> > > > > >>>>>>>>
> > > >
> > /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64
> > "
> > > > > >>>>>>>>
> > > > >
> > >/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\
> > x64"
> > > > > >>>>>>>> /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB
> > > > /IGNORE:4086
> > > > > >/MAP
> > > > > >>>>>>>> /OPT:REF /DEBUG /MACHINE:AMD64 /LTCG
> > Kernel32.lib
> > > > > >MSVCRTD.lib
> > > > > >>>>>>>> vcruntimed.lib ucrtd.lib Gdi32.lib
> > User32.lib Winmm.lib
> > > > > Advapi32.lib
> > > > > >>>>>>>> MSFT:*_*_X64_ASM_FLAGS            ==
> > /nologo /W3 /WX /c /Cx
> > > > /Zd
> > > > > >/W0
> > > > > >>>>> /Zi
> > > > > >>>>>>>> MSFT:*_*_X64_ASMLINK_FLAGS        ==
> > /link /nologo
> > > > > >>>>>>>> +
> > > > > >>>>>>>> +  GCC:*_CLANG9_X64_DLINK_FLAGS ==
> > > > > >>>>>>>> /out:"$(BIN_DIR)\$(BASE_NAME).exe"
> > /base:0x10000000
> > > > > >>>>>>>> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> > > > > >>>>>>>>
> > > >
> > /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64
> > "
> > > > > >>>>>>>>
> > > > >
> > >/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\
> > x64"
> > > > > >>>>>>>> /LIBPATH:"%VCToolsInstallDir%lib\x64"
> > /NOLOGO
> > > > > >>>>> /SUBSYSTEM:CONSOLE
> > > > > >>>>>>>> /NODEFAULTLIB /IGNORE:4086  /OPT:REF
> > /DEBUG
> > > > > >/MACHINE:AMD64
> > > > > >>>>>>>> Kernel32.lib MSVCRTD.lib vcruntimed.lib
> > ucrtd.lib
> > > > > >>>>>>>> Gdi32.lib
> > > > > >User32.lib
> > > > > >>>>>>>> Winmm.lib Advapi32.lib /lldmap
> > > > > >>>>>>>>
> > /EXPORT:InitializeDriver=_ModuleEntryPoint
> > > > > >>>>>>>> +  GCC:*_CLANG9_X64_CC_FLAGS == -m64 -g -
> > fshort-wchar
> > > > > >>>>>>>> + -fno-strict-aliasing -Wall -c -include
> > AutoGen.h -D
> > > > > >>>>>>>> + _CRT_SECURE_NO_WARNINGS -Wnonportable-
> > include-
> > > path
> > > > -D
> > > > > >>>>> UNICODE
> > > > > >>>>>>>> -D
> > > > > >>>>>>>> + _CRT_SECURE_NO_DEPRECATE
> > > > > >>>>>>>> +
> > > > > >>>>>>>> +  GCC:*_CLANG9_IA32_DLINK_FLAGS ==
> > > > > >>>>>>>> /out:"$(BIN_DIR)\$(BASE_NAME).exe"
> > /base:0x10000000
> > > > > >>>>>>>> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> > > > > >>>>>>>>
> > > >
> > /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86
> > "
> > > > > >>>>>>>>
> > > > >
> > >/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\
> > x86"
> > > > > >>>>>>>> /LIBPATH:"%VCToolsInstallDir%ib\x86"
> > /NOLOGO
> > > > > >>>>> /SUBSYSTEM:CONSOLE
> > > > > >>>>>>>> /NODEFAULTLIB /IGNORE:4086  /OPT:REF
> > /DEBUG
> > > > /MACHINE:I386
> > > > > >>>>>>>> Kernel32.lib MSVCRTD.lib vcruntimed.lib
> > ucrtd.lib
> > > > > >>>>>>>> Gdi32.lib
> > > > > >User32.lib
> > > > > >>>>>>>> Winmm.lib Advapi32.lib /lldmap
> > > > > >>>>>>>>
> > /EXPORT:InitializeDriver=_ModuleEntryPoint
> > > > > >>>>>>>> +  GCC:*_CLANG9_IA32_CC_FLAGS == -m32 -g
> > -fshort-wchar
> > > > > >>>>>>>> + -fno-strict-aliasing -Wall -c -include
> > AutoGen.h -D
> > > > > >>>>>>>> + _CRT_SECURE_NO_WARNINGS -Wnonportable-
> > include-
> > > path
> > > > -D
> > > > > >>>>> UNICODE
> > > > > >>>>>>>> -D
> > > > > >>>>>>>> + _CRT_SECURE_NO_DEPRECATE
> > > > > >>>>>>>> --
> > > > > >>>>>>>> 2.13.0.windows.1
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> > 

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

[Liming Gao]

Ray:
 Thanks for your detail investigation. It is hard to decide the name, because this is not purely technical problem.
 I summary current feedback on this tool chain name as below. 
 The result shows that CLANGPDB is the acceptable tool chain name, although not every one prefers this name. 

Ray: CLANGCODEVIEW, CLANGCV or CLANGPDB.
Mike: CLANGCODEVIEW, CLANGCV or CLANGPDB.
Andrew: CLANGPE, CLANGPDB (Prefer)
Leif: CLANGPE (Prefer), CLANGPDB, PECLANG, PDBCLANG
Liming: CLANGPE (Prefer), CLANGPDB

Thanks
Liming
> -----Original Message-----
> From: Ni, Ray <ray.ni@intel.com>
> Sent: Tuesday, November 12, 2019 2:49 PM
> To: Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>; afish@apple.com;
> Leif Lindholm <leif.lindholm@linaro.org>
> Cc: Justen, Jordan L <jordan.l.justen@intel.com>; Shi, Steven <steven.shi@intel.com>
> Subject: RE: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
> 
> Mike,
> I did a simple research in the web and found the slides:
> https://llvm.org/devmtg/2016-11/Slides/Kleckner-CodeViewInLLVM.pdf
> 
> In page #3, it says:
> "CodeView is stored inside object files and PDBs"
> "PDB is a container format written by linker and read by debugger"
> 
> The relationships between terms are:
> "CodeView :: DWARF"
> "PDB :: dSYM"
> "PDB :: DWP"
> 
> 
> I also found information from "https://llvm.org/docs/PDB/index.html":
> "CodeView is another format which comes into the picture. While MSF
> defines the structure of the overall file, and PDB defines the set of streams
> that appear within the MSF file and the format of those streams, CodeView
> defines the format of symbol and type records that appear within specific
> streams."
> 
> With all these information, I am ok with any of CLANGCODEVIEW, CLANGCV or CLANGPDB.
> 
> Developers who care about symbolic debugging should be aware of what kind of
> debug symbol is generated by build.
> 
> Thanks,
> Ray
> 
> > -----Original Message-----
> > From: Kinney, Michael D <michael.d.kinney@intel.com>
> > Sent: Tuesday, November 12, 2019 11:48 AM
> > To: devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com>; Gao, Liming
> > <liming.gao@intel.com>; afish@apple.com; Leif Lindholm
> > <leif.lindholm@linaro.org>; Kinney, Michael D <michael.d.kinney@intel.com>
> > Cc: Justen, Jordan L <jordan.l.justen@intel.com>; Shi, Steven
> > <steven.shi@intel.com>
> > Subject: RE: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool
> > chain
> >
> > Ray,
> >
> > I agree that a name that represents the symbolic debug format makes more
> > sense.
> >
> > The term 'PE' is short for PE/COFF, and that is the required final output
> > format.  A toolchain profile that happens to go through other intermediate
> > formats (e.g.
> > elf or macho) before finally generating a PE/COFF image is usually not that
> > interesting to most developers.  So adding 'PE' to the name is redundant
> > information.
> >
> > The attribute of the images that does impact developers is the format of the
> > symbol information.  Even for Visual Studio, PDB is the file extension used
> > when the symbol information is placed in a separate file.  The Visual Studio
> > compilers do support putting the symbol information in a section of the
> > PE/COFF image.  EDK II builds happen to always use the PDB option to
> > minimize the size of firmware images. So PDB may not be the right name
> > either.  I think the symbol format in the PDB that is used is codeview.
> >
> > If we want to plan ahead for toolchain names perhaps:
> >
> > Codeview: CLANGCODEVIEW or CLANGCV or CLANGPDB
> > Dwarf:    CLANGDWARF
> >
> > Best regards,
> >
> > Mike
> >
> > > -----Original Message-----
> > > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Ni,
> > Ray
> > > Sent: Monday, November 11, 2019 7:23 PM
> > > To: devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com>; Gao, Liming
> > > <liming.gao@intel.com>; afish@apple.com; Leif Lindholm
> > > <leif.lindholm@linaro.org>
> > > Cc: Justen, Jordan L <jordan.l.justen@intel.com>; Shi, Steven
> > > <steven.shi@intel.com>
> > > Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg:
> > > Enable CLANG9 tool chain
> > >
> > > And LLVM I believe is capable to support generating PE + DWARF.
> > > That's my second concern: Using CLANGPE may not imply PDB is used from
> > > a LLVM expert's understanding.
> > >
> > >
> > > > -----Original Message-----
> > > > From: devel@edk2.groups.io <devel@edk2.groups.io> On
> > > Behalf Of Ni, Ray
> > > > Sent: Tuesday, November 12, 2019 11:10 AM
> > > > To: devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com>;
> > > Gao, Liming
> > > > <liming.gao@intel.com>; afish@apple.com; Leif Lindholm
> > > > <leif.lindholm@linaro.org>
> > > > Cc: Justen, Jordan L <jordan.l.justen@intel.com>; Shi,
> > > Steven
> > > > <steven.shi@intel.com>
> > > > Subject: Re: [edk2-devel] [Patch v3 10/11]
> > > EmulatorPkg: Enable CLANG9
> > > > tool chain
> > > >
> > > > My point is if we choose CLANGPE, for LLVM toolchain
> > > supporting DWARF
> > > > debug symbol, there is no proper name left: we cannot
> > > use CLANGELF.
> > > >
> > > > Andrew, you said CLANGPDE. A typo?
> > > >
> > > > > -----Original Message-----
> > > > > From: devel@edk2.groups.io <devel@edk2.groups.io> On
> > > Behalf Of Ni,
> > > > Ray
> > > > > Sent: Tuesday, November 12, 2019 9:46 AM
> > > > > To: Gao, Liming <liming.gao@intel.com>;
> > > devel@edk2.groups.io;
> > > > > afish@apple.com; Leif Lindholm
> > > <leif.lindholm@linaro.org>
> > > > > Cc: Justen, Jordan L <jordan.l.justen@intel.com>;
> > > Shi, Steven
> > > > > <steven.shi@intel.com>
> > > > > Subject: Re: [edk2-devel] [Patch v3 10/11]
> > > EmulatorPkg: Enable
> > > > > CLANG9 tool chain
> > > > >
> > > > > Liming,
> > > > > What name will be chosen when in future someone
> > > wants a LLVM
> > > > toolchain
> > > > > which supports DWARF debug symbol?
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Gao, Liming <liming.gao@intel.com>
> > > > > > Sent: Tuesday, November 12, 2019 8:41 AM
> > > > > > To: devel@edk2.groups.io; afish@apple.com; Leif
> > > Lindholm
> > > > > > <leif.lindholm@linaro.org>
> > > > > > Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L
> > > > > > <jordan.l.justen@intel.com>; Shi, Steven
> > > <steven.shi@intel.com>;
> > > > > > Gao, Liming <liming.gao@intel.com>
> > > > > > Subject: RE: [edk2-devel] [Patch v3 10/11]
> > > EmulatorPkg: Enable
> > > > > > CLANG9 tool chain
> > > > > >
> > > > > > Thanks for your feedback. I will choose CLANGPE as
> > > the tool chain name.
> > > > > >
> > > > > > Thanks
> > > > > > Liming
> > > > > > >-----Original Message-----
> > > > > > >From: devel@edk2.groups.io
> > > [mailto:devel@edk2.groups.io] On
> > > > > > >Behalf Of Andrew Fish via Groups.Io
> > > > > > >Sent: Tuesday, November 12, 2019 12:52 AM
> > > > > > >To: Leif Lindholm <leif.lindholm@linaro.org>
> > > > > > >Cc: Ni, Ray <ray.ni@intel.com>; Gao, Liming
> > > > > > ><liming.gao@intel.com>; devel@edk2.groups.io;
> > > Justen, Jordan L
> > > > > > ><jordan.l.justen@intel.com>; Shi, Steven
> > > <steven.shi@intel.com>
> > > > > > >Subject: Re: [edk2-devel] [Patch v3 10/11]
> > > EmulatorPkg: Enable
> > > > > > >CLANG9 tool chain
> > > > > > >
> > > > > > >Either works for me too. I like the PDE ending a
> > > little more, but
> > > > > > >agree it is a little more obscure.
> > > > > > >> On Nov 11, 2019, at 8:39 AM, Leif Lindholm
> > > > > > >> <leif.lindholm@linaro.org>
> > > > > > wrote:
> > > > > > >>
> > > > > > >> On Fri, Nov 08, 2019 at 03:34:59AM +0000, Ni,
> > > Ray wrote:
> > > > > > >>> Liming,
> > > > > > >>> PE is UEFI spec required executable binary
> > > format. I like
> > > > > > >>> CLANGPDB more than CLANGPE given LLVM may
> > > generate DRAWF
> > > > debug
> > > > > > >>> symbol
> > > > > > >even
> > > > > > >>> when generating PE.
> > > > > > >>
> > > > > > >> Just a comment here to point out that while (as
> > > I stated in
> > > > > > >> reply to
> > > > > > >> Liming) my preference would be CLANGPE, I see
> > > the logic in the
> > > > > > >> above, and would be happy with either.
> > > > > > >>
> > > > > > >> (My reason for preferring CLANGPE is not
> > > exactly techincal - I
> > > > > > >> just expect more people to know what PE is than
> > > who know what
> > > > > > >> PDB
> > > > > > >> is.)
> > > > > > >>
> > > > > > >> Regards,
> > > > > > >>
> > > > > > >> Leif
> > > > > > >>
> > > > > > >>>> -----Original Message-----
> > > > > > >>>> From: Gao, Liming <liming.gao@intel.com>
> > > > > > >>>> Sent: Friday, November 8, 2019 9:50 AM
> > > > > > >>>> To: devel@edk2.groups.io;
> > > leif.lindholm@linaro.org; Andrew
> > > > > > >>>> Fish
> > > > > > ><afish@apple.com>
> > > > > > >>>> Cc: Ni, Ray <ray.ni@intel.com>; Justen,
> > > Jordan L
> > > > > > ><jordan.l.justen@intel.com>; Gao, Liming
> > > <liming.gao@intel.com>;
> > > > > > >Shi,
> > > > > > >>>> Steven <steven.shi@intel.com>
> > > > > > >>>> Subject: RE: [edk2-devel] [Patch v3 10/11]
> > > EmulatorPkg:
> > > > > > >>>> Enable
> > > > > > >>>> CLANG9
> > > > > > >tool chain
> > > > > > >>>>
> > > > > > >>>> Andrew and Leif:
> > > > > > >>>>  Thanks for your comment. CLANG9 is different
> > > from CLANG38.
> > > > > > >>>> And,
> > > > > > >CLANG9 will support LLVM9 or the above.
> > > > > > >>>>  So, this tool chain should have the specific
> > > word for its
> > > > > > >>>> purpose, and
> > > > > > >remove the version 9 to avoid the confuse.
> > > > > > >>>>
> > > > > > >>>>  I prefer the tool chain name as CLANGPE or
> > > CLANGPDB. CLANGPE
> > > > > may
> > > > > > >be better. Now, CLANG9 tool chain
> > > > > > >>>>  build rule family just uses CLANGPE. CLANGPE
> > > lets user know
> > > > > > >>>> this tool
> > > > > > >chain generates PE/COFF image.
> > > > > > >>>>  And, PE/COFF image debug symbol is PDB. So,
> > > PE also means PDB.
> > > > > > >>>>
> > > > > > >>>>  Last, I just review the changes. Tool chain
> > > name update is
> > > > > > >>>> not big. If you
> > > > > > >accept CLANGPE as tool chain name,
> > > > > > >>>>  I will send the patch soon to catch 201911
> > > stable tag.
> > > > > > >>>>
> > > > > > >>>> Thanks
> > > > > > >>>> Liming
> > > > > > >>>>> -----Original Message-----
> > > > > > >>>>> From: devel@edk2.groups.io
> > > [mailto:devel@edk2.groups.io] On
> > > > > > Behalf
> > > > > > >Of Leif
> > > > > > >>>>> Lindholm
> > > > > > >>>>> Sent: Friday, November 08, 2019 2:37 AM
> > > > > > >>>>> To: Andrew Fish <afish@apple.com>
> > > > > > >>>>> Cc: devel@edk2.groups.io; Gao, Liming
> > > > > > >>>>> <liming.gao@intel.com>; Ni, Ray
> > > <ray.ni@intel.com>; Justen,
> > > > > > >>>>> Jordan L <jordan.l.justen@intel.com>
> > > > > > >>>>> Subject: Re: [edk2-devel] [Patch v3 10/11]
> > > EmulatorPkg:
> > > > > > >>>>> Enable
> > > > > > >>>>> CLANG9
> > > > > > >tool
> > > > > > >>>>> chain
> > > > > > >>>>>
> > > > > > >>>>> Hi Andrew,
> > > > > > >>>>>
> > > > > > >>>>> Yeah, I'm pretty easy with regards to what
> > > we change it to.
> > > > > > >>>>> Although if we're bikeshedding, I would
> > > prefer not using _
> > > > > > >>>>> in the toolchain profile name.
> > > > > > >>>>>
> > > > > > >>>>> I'm ... optimistic ... it won't break any of
> > > my existing
> > > > > > >>>>> scripts, but since the build system uses it
> > > as a <toolchain
> > > > > > >>>>> profile>_<architecture>_<build target>
> > > separator, it would
> > > > > > >>>>> profile>be nice
> > > > > > >>>>> if we didn't risk confusion there.
> > > > > > >>>>>
> > > > > > >>>>> (I would be totally happy with PECLANG,
> > > CLANGPE, PDBCLANG,
> > > > > > >CLANGPDB or
> > > > > > >>>>> something along those lines.)
> > > > > > >>>>>
> > > > > > >>>>> Regards,
> > > > > > >>>>>
> > > > > > >>>>> Leif
> > > > > > >>>>>
> > > > > > >>>>> On Thu, Nov 07, 2019 at 11:54:04AM -0600,
> > > Andrew Fish wrote:
> > > > > > >>>>>> Leif,
> > > > > > >>>>>>
> > > > > > >>>>>> I think I proposed CLANG_PDB or
> > > CLANG_PECOFF. I seem to
> > > > > > >>>>>> like
> > > > > > >>>>> CLANG_PDB as assuming the PDE debugging
> > > experience is
> > > > > > >awesome/exists
> > > > > > >>>>> on Linux and macOS is not a given.
> > > > > > >>>>>>
> > > > > > >>>>>> Thanks,
> > > > > > >>>>>>
> > > > > > >>>>>> Andrew Fish
> > > > > > >>>>>>
> > > > > > >>>>>>> On Nov 7, 2019, at 11:19 AM, Leif Lindholm
> > > > > > >>>>>>> <leif.lindholm@linaro.org>
> > > > > > >>>>> wrote:
> > > > > > >>>>>>>
> > > > > > >>>>>>> Oops, sorry, missed this in search.
> > > > > > >>>>>>>
> > > > > > >>>>>>> On Wed, Oct 30, 2019 at 03:43:44PM +0000,
> > > Liming Gao wrote:
> > > > > > >>>>>>>> Andrew:
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> I prefer to keep short CLANG9 as the tool
> > > chain name. I
> > > > > > >>>>>>>> add wiki page
> > > > > > >>>>>>>>
> > > > >
> > > https://github.com/tianocore/tianocore.github.io/wiki/CL
> > > ANG9-
> > > > > > >Tools-
> > > > > > >>>>> Chain
> > > > > > >>>>>>>> to introduce it.
> > > > > > >>>>>>>
> > > > > > >>>>>>> Why should users be expected to go and
> > > read documentation
> > > > in
> > > > > > >order to
> > > > > > >>>>>>> learn that fundamental and incompatible
> > > changes to output
> > > > > > >>>>>>> and
> > > > > > >debug
> > > > > > >>>>>>> format has been made as part of what looks
> > > like a simple
> > > > > > >>>>>>> version
> > > > > > >bump?
> > > > > > >>>>>>>
> > > > > > >>>>>>>> And, we have CLANG38 tool chain. It
> > > generates ELF image
> > > > > > >>>>>>>> and DWARF debug symbol format. It can
> > > work with LLVM 9.0
> > > > release.
> > > > > > >>>>>>>> Current tool chain tag name includes
> > > compiler name and
> > > > version.
> > > > > > >>>>>>>> There is no specific info in the tool
> > > chain name. The
> > > > > > >>>>>>>> developer can get the more tool chain
> > > information from
> > > > > > >>>>>>>> wiki
> > > > > page.
> > > > > > >>>>>>>
> > > > > > >>>>>>> We aleady have the problem that people
> > > think they need to
> > > > > > >>>>>>> use
> > > > > > >GCC5 to
> > > > > > >>>>>>> build EDK2 since that is the highest named
> > > GCC toolchain profile.
> > > > > > >>>>>>>
> > > > > > >>>>>>> Let's not make this situation *worse* by
> > > setting up a
> > > > > > >multidimensional
> > > > > > >>>>>>> feature matrix, based off random numerical
> > > values.
> > > > > > >>>>>>>
> > > > > > >>>>>>> So say that we next have a pressing need
> > > to create a new
> > > > > > >>>>>>> toolchain profile for clang 10, using the
> > > old ELF mechanism.
> > > > > > >>>>>>> Are you then suggesting we set up a table
> > > on said wiki
> > > > > > >>>>>>> page where people have to
> > > > > > >go
> > > > > > >>>>>>> and look up what the object and debug
> > > formats are for each
> > > > > > >CLANG##
> > > > > > >>>>>>> toolchain profile?
> > > > > > >>>>>>>
> > > > > > >>>>>>> And what if you then end up needing to do
> > > the same for the
> > > > > > >>>>>>> PDB flavour?
> > > > > > >>>>>>>
> > > > > > >>>>>>>> CLANG9 is designed to support Emulator
> > > for Windows host
> > > > only.
> > > > > > >>>>>>>
> > > > > > >>>>>>> Which is why it makes no sense to name it
> > > as a successor
> > > > > > >>>>>>> of CLANG38.
> > > > > > >>>>>>>
> > > > > > >>>>>>>> CLANG38 may be used for Emulator in Linux
> > > or Mac. I don’t
> > > > > > >>>>>>>> try it before.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> CLANG9 goal is to align the same compiler
> > > in the
> > > > > > >>>>>>>> different host development environment.
> > > It can replace VS
> > > > > > >>>>>>>> or GCC compiler. On Windows Host, I
> > > verify VS debugger
> > > > > > >>>>>>>> for the source
> > > > > level debug.
> > > > > > >>>>>>>> On Linux host, I have not verified llvm
> > > debugger. I will
> > > > > > >>>>>>>> investigate the debugger solution for
> > > OVMF in Linux host.
> > > > > > >>>>>>>
> > > > > > >>>>>>> We are not asking you to throw out this
> > > toolchain profile.
> > > > > > >>>>>>>
> > > > > > >>>>>>> We are saying that since the functionality
> > > it provides is
> > > > > > >>>>>>> completely unrelated to that of CLANG38,
> > > it should not be
> > > > > > >>>>>>> named in a way that suggests it is merely
> > > a revision update.
> > > > > > >>>>>>>
> > > > > > >>>>>>> /
> > > > > > >>>>>>>   Leif
> > > > > > >>>>>>>
> > > > > > >>>>>>>> Thanks
> > > > > > >>>>>>>> Liming
> > > > > > >>>>>>>> From: afish@apple.com <afish@apple.com>
> > > > > > >>>>>>>> Sent: Saturday, October 26, 2019 2:45 AM
> > > > > > >>>>>>>> To: devel@edk2.groups.io; Gao, Liming
> > > > > > >>>>>>>> <liming.gao@intel.com>
> > > > > > >>>>>>>> Cc: Ni, Ray <ray.ni@intel.com>; Justen,
> > > Jordan L
> > > > > > >>>>> <jordan.l.justen@intel.com>
> > > > > > >>>>>>>> Subject: Re: [edk2-devel] [Patch v3
> > > 10/11] EmulatorPkg:
> > > > > > >>>>>>>> Enable
> > > > > > >CLANG9
> > > > > > >>>>> tool chain
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Liming,
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Sorry I missed this mail. Thanks for the
> > > info! I was
> > > > > > >>>>>>>> doing some
> > > > > > >research
> > > > > > >>>>> into this too and now I think I finally
> > > understand. I think
> > > > > > >>>>> the name for
> > > > > > >the tool
> > > > > > >>>>> chain really confused me and we should think
> > > about changing
> > > > > > >>>>> the
> > > > > > name.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> From what I understand CLANG9 means
> > > produce PE/COFF
> > > > > directly
> > > > > > >and
> > > > > > >>>>> used the PDB debugging format. I see from
> > > the llvm site that
> > > > > > >>>>> the linker
> > > > > > >can
> > > > > > >>>>> produce PDB directly as you mention. This
> > > all makes sense to
> > > > > > >>>>> me now as
> > > > > > >LLVM
> > > > > > >>>>> tries to make it easy to be a drop in
> > > replacement for VC++ or GCC.
> > > > > > >>>>> So
> > > > > > >this tool
> > > > > > >>>>> chain is designed to be able to cross build
> > > a "Windows App"
> > > > > > >>>>> on a Linux or macOS. It also looks like the
> > > llvm debugger,
> > > > > > >>>>> lldb, is lagging in its support
> > > > > > >for
> > > > > > >>>>> PDB based debugging.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Anyway I think Leif and I agree the
> > > toolchain name is
> > > > > > >>>>>>>> very
> > > > > > confusing.
> > > > > > >I'd
> > > > > > >>>>> rather see it called CLANG9_WIN or
> > > CLANG_PDB.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> On Oct 18, 2019, at 7:27 AM, Liming Gao
> > > > > > >>>>>
> > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > wrote:
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Andrew:
> > > > > > >>>>>>>> Here is the cover letter on CLANG9
> > > introduction.
> > > > > > >>>>> https://edk2.groups.io/g/devel/message/49157
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> 1)      Yes. CLANG9 tool chain is added
> > > to directly generate
> > > > > PE/COFF
> > > > > > >image
> > > > > > >>>>> (EFI image).
> > > > > > >>>>>>>> This tool chain uses LLVM clang C
> > > compiler and lld
> > > > > > >>>>>>>> linker, generates
> > > > > > >>>>> PE/COFF
> > > > > > >>>>>>>> image and PDB compatible debug symbol
> > > format. Now, it
> > > > > > supports
> > > > > > >>>>> IA32/X64 Archs.
> > > > > > >>>>>>>> LLVM clang C compiler and lld linker are
> > > the standalone
> > > > > > >>>>>>>> tool
> > > > set.
> > > > > > >They
> > > > > > >>>>> don’t depend other lib to generate PE/COFF
> > > image.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> 2)      Yes. CLANG9 is the cross OS tool
> > > chain. It can work on
> > > > > > >>>>> Windows/Linux/Mac host OS.
> > > > > > >>>>>>>> LLVM LLD linker uses Windows style
> > > arguments. I verify
> > > > > > >>>>>>>> CLANG9 for
> > > > > > >>>>> Ovmf3264 in Windows/Linux host OS.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> On Linux can you source level debug Ovmf?
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> 3)     This patch enables WinHost in
> > > Windows. It doesn’t enable
> > > > > > >UnixHost.
> > > > > > >>>>> Now, EmulatorPkg with CLANG9 only works on
> > > Windows Host.
> > > > > > >>>>>>>> This patch can make other modules pass
> > > build in
> > > > > > >Windows/Linux/Mac
> > > > > > >>>>> only if LLVM9 tool set is installed.
> > > > > > >>>>>>>> But, the generated image may not work on
> > > Linux/Mac. I
> > > > > > >>>>>>>> agree
> > > > > > >below
> > > > > > >>>>> linker flags are specific to windows host.
> > > > > > >>>>>>>> So, I suggest to add the conditional
> > > statement of
> > > > > > >$(WIN_HOST_BUILD)
> > > > > > >>>>> == TRUE for them.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> For the EmulatorPkg the Host is a native
> > > App for that OS
> > > > > > >>>>>>>> you build on,
> > > > > > >but
> > > > > > >>>>> it seems like CLANG9 is targeted to build
> > > Windows Apps. I'm
> > > > > > >>>>> not sure
> > > > > > >but you
> > > > > > >>>>> might be able to override all the linker
> > > commands to build a
> > > > > > >>>>> native app,
> > > > > > >or just
> > > > > > >>>>> use the system linker for the Host?
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> I'm not sure how well debugging will work
> > > mixing PDB and
> > > > > > >>>>>>>> DWARF
> > > > > > >>>>> symbol formats?
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Thanks,
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Andrew Fish
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> !if $(WIN_HOST_BUILD) == TRUE
> > > > > > >>>>>>>> GCC:*_CLANG9_*_DLINK_FLAGS     =
> > > /ALIGN:4096
> > > > > > /FILEALIGN:4096
> > > > > > >>>>> /SUBSYSTEM:CONSOLE
> > > > > > >>>>>>>> GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
> > > > > > >>>>>
> > > /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> > > /BASE:0x10000
> > > > > > >>>>>>>> GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
> > > > > > >>>>>
> > > /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> > > /BASE:0x10000
> > > > > > >>>>>>>> !endif
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Thanks
> > > > > > >>>>>>>> Liming
> > > > > > >>>>>>>> From:
> > > afish@apple.com<mailto:afish@apple.com>
> > > > > > >>>>> <afish@apple.com<mailto:afish@apple.com>>
> > > > > > >>>>>>>> Sent: Friday, October 18, 2019 1:15 AM
> > > > > > >>>>>>>> To: Ni, Ray
> > > <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > > > > > >>>>>>>> Cc: Gao, Liming
> > > > > >
> > > ><liming.gao@intel.com<mailto:liming.gao@intel.com>>;
> > > > > > >>>>>
> > > devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> > > Justen,
> > > > > > Jordan
> > > > > > >>>>> L
> > > > > > >>>>>
> > > <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.
> > > com>
> > > > > > >>>>> >
> > > > > > >>>>>>>> Subject: Re: [Patch v3 10/11]
> > > EmulatorPkg: Enable CLANG9
> > > > > > >>>>>>>> tool chain
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Ray,
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Sorry I'm coming a little late to this
> > > and I'm confused.
> > > > > > >>>>>>>> I have some
> > > > > > >>>>> questions?
> > > > > > >>>>>>>> 1) Does CLANG9 imply CLANGPE?
> > > > > > >>>>>>>> 2) Does CLANGPE work on Linux and macOS?
> > > Can you pass the
> > > > > > >Windows
> > > > > > >>>>> style arguments to CLANGPE linker on Linux
> > > and macOS?
> > > > > > >>>>>>>> 3) For the EmulatorPkg don't you have the
> > > extra
> > > > > > >>>>>>>> requirement that
> > > > > > >>>>> compiler needs a standard C lib (or platform
> > > specific libs)
> > > > > > >>>>> to
> > > > function?
> > > > > > >>>>>>>>      a) GCC:*_CLANG9_*_DLINK_FLAGS in
> > > EmulatorPkg.dsc
> > > > > seems
> > > > > > to
> > > > > > >>>>> imply the Linux and macOS systems will have
> > > a Windows SKD
> > > > > > >>>>> dir and a
> > > > > > >lot of
> > > > > > >>>>> Windows DLLs? Does all that come when you
> > > install CLANG9
> > > > > > >>>>> when
> > > > > > you
> > > > > > >install
> > > > > > >>>>> it on Linux or macOS?
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> So I guess I'm asking is the linker
> > > really the same for
> > > > > > >>>>>>>> CLANG9 on all
> > > > > > >>>>> systems? I guess the answer could be yes,
> > > but it seems the C
> > > > > > >>>>> lib for the
> > > > > > >Host
> > > > > > >>>>> App is still an App for that OS and is OS
> > > dependent?
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Sorry if I'm missing something
> > > fundamental and this is a
> > > > > > >>>>>>>> dumb
> > > > > > >question.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Thanks,
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Andrew Fish
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> On Oct 17, 2019, at 12:27 AM, Ni, Ray
> > > > > > >>>>> <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > > wrote:
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Liming,
> > > > > > >>>>>>>> Emulator is using a generic SEC module.
> > > The host specific
> > > > > > >>>>>>>> module is
> > > > > > >called
> > > > > > >>>>> "Host".
> > > > > > >>>>>>>> So I prefer to change the macro to
> > > "WIN_HOST_BUILD", with
> > > > > > >>>>>>>> this
> > > > > > >change,
> > > > > > >>>>> Reviewed-by: Ray Ni
> > > > > > >>>>> <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> -----Original Message-----
> > > > > > >>>>>>>> From: Gao, Liming
> > > > > >
> > > ><liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > > >>>>>>>> Sent: Thursday, October 17, 2019 2:56 PM
> > > > > > >>>>>>>> To:
> > > devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> > > > > > >>>>>>>> Cc: Justen, Jordan L
> > > > > > >>>>>
> > > <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.
> > > com>
> > > > > > >>>>> >;
> > > > > > >Andrew
> > > > > > >>>>> Fish
> > > > > > >>>>>>>>
> > > <afish@apple.com<mailto:afish@apple.com>>; Ni, Ray
> > > > > > >>>>> <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > > > > > >>>>>>>> Subject: [Patch v3 10/11] EmulatorPkg:
> > > Enable CLANG9 tool
> > > > > > >>>>>>>> chain
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> BZ:
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=1603
> > > > > > >>>>>>>> 1. Add WIN_SEC_BUILD macro check for
> > > CLANG9 tool chain
> > > > > > >>>>>>>> build
> > > > > > >>>>>>>> -
> > > > > > p
> > > > > > >>>>>>>> EmulatorPkg\EmulatorPkg.dsc -a IA32 -
> > > > DWIN_SEC_BUILD=TRUE
> > > > > -t
> > > > > > >>>>> CLANG9
> > > > > > >>>>>>>> build -p EmulatorPkg\EmulatorPkg.dsc -a
> > > X64 -
> > > > > > >DWIN_SEC_BUILD=TRUE -t
> > > > > > >>>>>>>> CLANG9 2. Append CLANG CC and LINK flags
> > > to generate
> > > > > windows
> > > > > > >HOST.
> > > > > > >>>>>>>> 3. Fix WinHost issue to call
> > > GetProcessAffinityMask() API.
> > > > > > >>>>>>>> The input parameter should be UINTN
> > > pointer instead of
> > > > > UINT32
> > > > > > >pointer.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Cc: Jordan Justen
> > > > > > >>>>>
> > > <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.
> > > com>
> > > > > > >>>>> >
> > > > > > >>>>>>>> Cc: Andrew Fish
> > > <afish@apple.com<mailto:afish@apple.com>>
> > > > > > >>>>>>>> Cc: Ray Ni
> > > <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> > > > > > >>>>>>>> Signed-off-by: Liming Gao
> > > > > > >>>>>
> > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > > >>>>>>>> ---
> > > > > > >>>>>>>> EmulatorPkg/Win/Host/WinHost.c   | 6 +++-
> > > --
> > > > > > >>>>>>>> EmulatorPkg/EmulatorPkg.dsc      | 7
> > > ++++++-
> > > > > > >>>>>>>> EmulatorPkg/Win/Host/WinHost.inf | 6
> > > ++++++
> > > > > > >>>>>>>> 3 files changed, 15 insertions(+), 4
> > > deletions(-)
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> diff --git
> > > a/EmulatorPkg/Win/Host/WinHost.c
> > > > > > >>>>>>>> b/EmulatorPkg/Win/Host/WinHost.c index
> > > > > > 9aba3c8959..e40ce32548
> > > > > > >>>>> 100644
> > > > > > >>>>>>>> --- a/EmulatorPkg/Win/Host/WinHost.c
> > > > > > >>>>>>>> +++ b/EmulatorPkg/Win/Host/WinHost.c
> > > > > > >>>>>>>> @@ -356,7 +356,7 @@ Returns:
> > > > > > >>>>>>>> INTN
> > > > > > >>>>>>>> EFIAPI
> > > > > > >>>>>>>> main (
> > > > > > >>>>>>>> -  IN  INTN  Argc,
> > > > > > >>>>>>>> +  IN  INT  Argc,
> > > > > > >>>>>>>> IN  CHAR8 **Argv,
> > > > > > >>>>>>>> IN  CHAR8 **Envp
> > > > > > >>>>>>>> )
> > > > > > >>>>>>>> @@ -391,8 +391,8 @@ Returns:
> > > > > > >>>>>>>> VOID                  *SecFile;
> > > > > > >>>>>>>> CHAR16                *MemorySizeStr;
> > > > > > >>>>>>>> CHAR16
> > > *FirmwareVolumesStr;
> > > > > > >>>>>>>> -  UINT32
> > > ProcessAffinityMask;
> > > > > > >>>>>>>> -  UINT32
> > > SystemAffinityMask;
> > > > > > >>>>>>>> +  UINTN
> > > ProcessAffinityMask;
> > > > > > >>>>>>>> +  UINTN
> > > SystemAffinityMask;
> > > > > > >>>>>>>> INT32                 LowBit;
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> //
> > > > > > >>>>>>>> diff --git a/EmulatorPkg/EmulatorPkg.dsc
> > > > > > >>>>> b/EmulatorPkg/EmulatorPkg.dsc
> > > > > > >>>>>>>> index 20f1187713..72532f5daf 100644
> > > > > > >>>>>>>> --- a/EmulatorPkg/EmulatorPkg.dsc
> > > > > > >>>>>>>> +++ b/EmulatorPkg/EmulatorPkg.dsc
> > > > > > >>>>>>>> @@ -237,9 +237,10 @@
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> [Components]
> > > > > > >>>>>>>> !if "IA32" in $(ARCH) || "X64" in $(ARCH)
> > > > > > >>>>>>>> -  !if "MSFT" in $(FAMILY)
> > > > > > >>>>>>>> +  !if "MSFT" in $(FAMILY) ||
> > > $(WIN_SEC_BUILD) == TRUE
> > > > > > >>>>>>>>   ##
> > > > > > >>>>>>>>   #  Emulator, OS WIN application
> > > > > > >>>>>>>> +    #  CLANG9 is cross OS tool chain. It
> > > depends on
> > > > > > >>>>>>>> + WIN_SEC_BUILD
> > > > > > >>>>> macro.
> > > > > > >>>>>>>>   ##
> > > > > > >>>>>>>>   EmulatorPkg/Win/Host/WinHost.inf !else
> > > @@ -419,7
> > > > > > >>>>>>>> +420,11
> > > > > > @@
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> MSFT:DEBUG_*_*_CC_FLAGS = /Od /Oy-
> > > > > > MSFT:NOOPT_*_*_CC_FLAGS =
> > > > > > >>>>>>>> /Od /Oy-
> > > > > > >>>>>>>> +  GCC:DEBUG_CLANG9_*_CC_FLAGS =-O0 -Wno-
> > > unused-
> > > > > > >command-
> > > > > > >>>>> line-
> > > > > > >>>>>>>> argument
> > > > > > >>>>>>>> + -Wno-incompatible-pointer-types -Wno-
> > > enum-conversion
> > > > > > >>>>>>>> + -Wno-incompatible-pointer-types -Wno-
> > > sometimes-
> > > > > > uninitialized
> > > > > > >>>>>>>> + -Wno-constant-conversion -Wno-main-
> > > return-type
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> MSFT:*_*_*_DLINK_FLAGS     = /ALIGN:4096
> > > /FILEALIGN:4096
> > > > > > >>>>>>>> /SUBSYSTEM:CONSOLE
> > > > > > >>>>>>>> MSFT:DEBUG_*_*_DLINK_FLAGS =
> > > > > > >>>>>>>>
> > > /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> > > > > /BASE:0x10000
> > > > > > >>>>>>>> MSFT:NOOPT_*_*_DLINK_FLAGS =
> > > > > > >>>>>>>>
> > > /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> > > > > /BASE:0x10000
> > > > > > >>>>>>>> +  GCC:*_CLANG9_*_DLINK_FLAGS     =
> > > /ALIGN:4096
> > > > > > >/FILEALIGN:4096
> > > > > > >>>>>>>> /SUBSYSTEM:CONSOLE
> > > > > > >>>>>>>> +  GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
> > > > > > >>>>>>>> +
> > > /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> > > > > > /BASE:0x10000
> > > > > > >>>>>>>> + GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
> > > > > > >>>>>>>> +
> > > /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT)
> > > > > > /BASE:0x10000
> > > > > > >>>>>>>> diff --git
> > > a/EmulatorPkg/Win/Host/WinHost.inf
> > > > > > >>>>>>>> b/EmulatorPkg/Win/Host/WinHost.inf
> > > > > > >>>>>>>> index 631d5a6470..1adca10d79 100644
> > > > > > >>>>>>>> --- a/EmulatorPkg/Win/Host/WinHost.inf
> > > > > > >>>>>>>> +++ b/EmulatorPkg/Win/Host/WinHost.inf
> > > > > > >>>>>>>> @@ -95,3 +95,9 @@
> > > > > > >>>>>>>> MSFT:*_VS2017_X64_DLINK_FLAGS      =
> > > > > > >>>>>>>> /LIBPATH:"%VCToolsInstallDir%lib\x64"
> > > > > > >>>>>>>>
> > > > >
> > > /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64
> > > "
> > > > > > >>>>>>>>
> > > > > >
> > > >/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\
> > > x64"
> > > > > > >>>>>>>> /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB
> > > > > /IGNORE:4086
> > > > > > >/MAP
> > > > > > >>>>>>>> /OPT:REF /DEBUG /MACHINE:AMD64 /LTCG
> > > Kernel32.lib
> > > > > > >MSVCRTD.lib
> > > > > > >>>>>>>> vcruntimed.lib ucrtd.lib Gdi32.lib
> > > User32.lib Winmm.lib
> > > > > > Advapi32.lib
> > > > > > >>>>>>>> MSFT:*_*_X64_ASM_FLAGS            ==
> > > /nologo /W3 /WX /c /Cx
> > > > > /Zd
> > > > > > >/W0
> > > > > > >>>>> /Zi
> > > > > > >>>>>>>> MSFT:*_*_X64_ASMLINK_FLAGS        ==
> > > /link /nologo
> > > > > > >>>>>>>> +
> > > > > > >>>>>>>> +  GCC:*_CLANG9_X64_DLINK_FLAGS ==
> > > > > > >>>>>>>> /out:"$(BIN_DIR)\$(BASE_NAME).exe"
> > > /base:0x10000000
> > > > > > >>>>>>>> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> > > > > > >>>>>>>>
> > > > >
> > > /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64
> > > "
> > > > > > >>>>>>>>
> > > > > >
> > > >/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\
> > > x64"
> > > > > > >>>>>>>> /LIBPATH:"%VCToolsInstallDir%lib\x64"
> > > /NOLOGO
> > > > > > >>>>> /SUBSYSTEM:CONSOLE
> > > > > > >>>>>>>> /NODEFAULTLIB /IGNORE:4086  /OPT:REF
> > > /DEBUG
> > > > > > >/MACHINE:AMD64
> > > > > > >>>>>>>> Kernel32.lib MSVCRTD.lib vcruntimed.lib
> > > ucrtd.lib
> > > > > > >>>>>>>> Gdi32.lib
> > > > > > >User32.lib
> > > > > > >>>>>>>> Winmm.lib Advapi32.lib /lldmap
> > > > > > >>>>>>>>
> > > /EXPORT:InitializeDriver=_ModuleEntryPoint
> > > > > > >>>>>>>> +  GCC:*_CLANG9_X64_CC_FLAGS == -m64 -g -
> > > fshort-wchar
> > > > > > >>>>>>>> + -fno-strict-aliasing -Wall -c -include
> > > AutoGen.h -D
> > > > > > >>>>>>>> + _CRT_SECURE_NO_WARNINGS -Wnonportable-
> > > include-
> > > > path
> > > > > -D
> > > > > > >>>>> UNICODE
> > > > > > >>>>>>>> -D
> > > > > > >>>>>>>> + _CRT_SECURE_NO_DEPRECATE
> > > > > > >>>>>>>> +
> > > > > > >>>>>>>> +  GCC:*_CLANG9_IA32_DLINK_FLAGS ==
> > > > > > >>>>>>>> /out:"$(BIN_DIR)\$(BASE_NAME).exe"
> > > /base:0x10000000
> > > > > > >>>>>>>> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> > > > > > >>>>>>>>
> > > > >
> > > /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86
> > > "
> > > > > > >>>>>>>>
> > > > > >
> > > >/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\
> > > x86"
> > > > > > >>>>>>>> /LIBPATH:"%VCToolsInstallDir%ib\x86"
> > > /NOLOGO
> > > > > > >>>>> /SUBSYSTEM:CONSOLE
> > > > > > >>>>>>>> /NODEFAULTLIB /IGNORE:4086  /OPT:REF
> > > /DEBUG
> > > > > /MACHINE:I386
> > > > > > >>>>>>>> Kernel32.lib MSVCRTD.lib vcruntimed.lib
> > > ucrtd.lib
> > > > > > >>>>>>>> Gdi32.lib
> > > > > > >User32.lib
> > > > > > >>>>>>>> Winmm.lib Advapi32.lib /lldmap
> > > > > > >>>>>>>>
> > > /EXPORT:InitializeDriver=_ModuleEntryPoint
> > > > > > >>>>>>>> +  GCC:*_CLANG9_IA32_CC_FLAGS == -m32 -g
> > > -fshort-wchar
> > > > > > >>>>>>>> + -fno-strict-aliasing -Wall -c -include
> > > AutoGen.h -D
> > > > > > >>>>>>>> + _CRT_SECURE_NO_WARNINGS -Wnonportable-
> > > include-
> > > > path
> > > > > -D
> > > > > > >>>>> UNICODE
> > > > > > >>>>>>>> -D
> > > > > > >>>>>>>> + _CRT_SECURE_NO_DEPRECATE
> > > > > > >>>>>>>> --
> > > > > > >>>>>>>> 2.13.0.windows.1
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>
> > > > > > >>>>>>>
> > > > > > >>>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > 

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

[Leif Lindholm]

On Fri, Nov 08, 2019 at 01:49:30AM +0000, Gao, Liming wrote:
> Andrew and Leif:
>   Thanks for your comment. CLANG9 is different from CLANG38. And, CLANG9 will support LLVM9 or the above. 
>   So, this tool chain should have the specific word for its purpose, and remove the version 9 to avoid the confuse. 
> 
>   I prefer the tool chain name as CLANGPE or CLANGPDB. CLANGPE may be better. Now, CLANG9 tool chain 
>   build rule family just uses CLANGPE. CLANGPE lets user know this tool chain generates PE/COFF image. 
>   And, PE/COFF image debug symbol is PDB. So, PE also means PDB.

My preference would also be CLANGPE.

>   Last, I just review the changes. Tool chain name update is not big. If you accept CLANGPE as tool chain name, 
>   I will send the patch soon to catch 201911 stable tag. 

I have no problem with this.

Thanks!

/
    Leif

> Thanks
> Liming
> >-----Original Message-----
> >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Leif
> >Lindholm
> >Sent: Friday, November 08, 2019 2:37 AM
> >To: Andrew Fish <afish@apple.com>
> >Cc: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>; Ni, Ray
> ><ray.ni@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>
> >Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool
> >chain
> >
> >Hi Andrew,
> >
> >Yeah, I'm pretty easy with regards to what we change it to.
> >Although if we're bikeshedding, I would prefer not using _ in the
> >toolchain profile name.
> >
> >I'm ... optimistic ... it won't break any of my existing scripts, but
> >since the build system uses it as a
> ><toolchain profile>_<architecture>_<build target> separator, it would
> >be nice if we didn't risk confusion there.
> >
> >(I would be totally happy with PECLANG, CLANGPE, PDBCLANG, CLANGPDB or
> >something along those lines.)
> >
> >Regards,
> >
> >Leif
> >
> >On Thu, Nov 07, 2019 at 11:54:04AM -0600, Andrew Fish wrote:
> >> Leif,
> >>
> >> I think I proposed CLANG_PDB or CLANG_PECOFF. I seem to like
> >CLANG_PDB as assuming the PDE debugging experience is awesome/exists
> >on Linux and macOS is not a given.
> >>
> >> Thanks,
> >>
> >> Andrew Fish
> >>
> >> > On Nov 7, 2019, at 11:19 AM, Leif Lindholm <leif.lindholm@linaro.org>
> >wrote:
> >> >
> >> > Oops, sorry, missed this in search.
> >> >
> >> > On Wed, Oct 30, 2019 at 03:43:44PM +0000, Liming Gao wrote:
> >> >> Andrew:
> >> >>
> >> >>  I prefer to keep short CLANG9 as the tool chain name. I add wiki
> >> >>  page
> >> >>  https://github.com/tianocore/tianocore.github.io/wiki/CLANG9-Tools-
> >Chain
> >> >>  to introduce it.
> >> >
> >> > Why should users be expected to go and read documentation in order to
> >> > learn that fundamental and incompatible changes to output and debug
> >> > format has been made as part of what looks like a simple version bump?
> >> >
> >> >>  And, we have CLANG38 tool chain. It generates ELF
> >> >>  image and DWARF debug symbol format. It can work with LLVM 9.0
> >> >>  release. Current tool chain tag name includes compiler name and
> >> >>  version. There is no specific info in the tool chain name. The
> >> >>  developer can get the more tool chain information from wiki page.
> >> >
> >> > We aleady have the problem that people think they need to use GCC5 to
> >> > build EDK2 since that is the highest named GCC toolchain profile.
> >> >
> >> > Let's not make this situation *worse* by setting up a multidimensional
> >> > feature matrix, based off random numerical values.
> >> >
> >> > So say that we next have a pressing need to create a new toolchain
> >> > profile for clang 10, using the old ELF mechanism. Are you then
> >> > suggesting we set up a table on said wiki page where people have to go
> >> > and look up what the object and debug formats are for each CLANG##
> >> > toolchain profile?
> >> >
> >> > And what if you then end up needing to do the same for the PDB
> >> > flavour?
> >> >
> >> >>  CLANG9 is designed to support Emulator for Windows host only.
> >> >
> >> > Which is why it makes no sense to name it as a successor of
> >> > CLANG38.
> >> >
> >> >>  CLANG38 may be used for Emulator in Linux or Mac. I don’t
> >> >>  try it before.
> >> >>
> >> >>  CLANG9 goal is to align the same compiler in the different host
> >> >>  development environment. It can replace VS or GCC compiler. On
> >> >>  Windows Host, I verify VS debugger for the source level debug. On
> >> >>  Linux host, I have not verified llvm debugger. I will investigate
> >> >>  the debugger solution for OVMF in Linux host.
> >> >
> >> > We are not asking you to throw out this toolchain profile.
> >> >
> >> > We are saying that since the functionality it provides is completely
> >> > unrelated to that of CLANG38, it should not be named in a way that
> >> > suggests it is merely a revision update.
> >> >
> >> > /
> >> >    Leif
> >> >
> >> >> Thanks
> >> >> Liming
> >> >> From: afish@apple.com <afish@apple.com>
> >> >> Sent: Saturday, October 26, 2019 2:45 AM
> >> >> To: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>
> >> >> Cc: Ni, Ray <ray.ni@intel.com>; Justen, Jordan L
> ><jordan.l.justen@intel.com>
> >> >> Subject: Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9
> >tool chain
> >> >>
> >> >> Liming,
> >> >>
> >> >> Sorry I missed this mail. Thanks for the info! I was doing some research
> >into this too and now I think I finally understand. I think the name for the tool
> >chain really confused me and we should think about changing the name.
> >> >>
> >> >> From what I understand CLANG9 means produce PE/COFF directly and
> >used the PDB debugging format. I see from the llvm site that the linker can
> >produce PDB directly as you mention. This all makes sense to me now as LLVM
> >tries to make it easy to be a drop in replacement for VC++ or GCC. So this tool
> >chain is designed to be able to cross build a "Windows App" on a Linux or
> >macOS. It also looks like the llvm debugger, lldb, is lagging in its support for
> >PDB based debugging.
> >> >>
> >> >>
> >> >> Anyway I think Leif and I agree the toolchain name is very confusing. I'd
> >rather see it called CLANG9_WIN or CLANG_PDB.
> >> >>
> >> >>
> >> >> On Oct 18, 2019, at 7:27 AM, Liming Gao
> ><liming.gao@intel.com<mailto:liming.gao@intel.com>> wrote:
> >> >>
> >> >> Andrew:
> >> >> Here is the cover letter on CLANG9 introduction.
> >https://edk2.groups.io/g/devel/message/49157
> >> >>
> >> >> 1)      Yes. CLANG9 tool chain is added to directly generate PE/COFF image
> >(EFI image).
> >> >> This tool chain uses LLVM clang C compiler and lld linker, generates
> >PE/COFF
> >> >> image and PDB compatible debug symbol format. Now, it supports
> >IA32/X64 Archs.
> >> >> LLVM clang C compiler and lld linker are the standalone tool set. They
> >don’t depend other lib to generate PE/COFF image.
> >> >>
> >> >> 2)      Yes. CLANG9 is the cross OS tool chain. It can work on
> >Windows/Linux/Mac host OS.
> >> >> LLVM LLD linker uses Windows style arguments. I verify CLANG9 for
> >Ovmf3264 in Windows/Linux host OS.
> >> >>
> >> >>
> >> >> On Linux can you source level debug Ovmf?
> >> >>
> >> >>
> >> >> 3)     This patch enables WinHost in Windows. It doesn’t enable UnixHost.
> >Now, EmulatorPkg with CLANG9 only works on Windows Host.
> >> >> This patch can make other modules pass build in Windows/Linux/Mac
> >only if LLVM9 tool set is installed.
> >> >> But, the generated image may not work on Linux/Mac. I agree below
> >linker flags are specific to windows host.
> >> >> So, I suggest to add the conditional statement of $(WIN_HOST_BUILD)
> >== TRUE for them.
> >> >>
> >> >>
> >> >> For the EmulatorPkg the Host is a native App for that OS you build on, but
> >it seems like CLANG9 is targeted to build Windows Apps. I'm not sure  but you
> >might be able to override all the linker commands to build a native app, or just
> >use the system linker for the Host?
> >> >>
> >> >> I'm not sure how well debugging will work mixing PDB and DWARF
> >symbol formats?
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Andrew Fish
> >> >>
> >> >>
> >> >>
> >> >> !if $(WIN_HOST_BUILD) == TRUE
> >> >>  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
> >/SUBSYSTEM:CONSOLE
> >> >>  GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
> >/EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> >> >>  GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
> >/EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> >> >> !endif
> >> >>
> >> >> Thanks
> >> >> Liming
> >> >> From: afish@apple.com<mailto:afish@apple.com>
> ><afish@apple.com<mailto:afish@apple.com>>
> >> >> Sent: Friday, October 18, 2019 1:15 AM
> >> >> To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> >> >> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>;
> >devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Justen, Jordan L
> ><jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
> >> >> Subject: Re: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
> >> >>
> >> >> Ray,
> >> >>
> >> >> Sorry I'm coming a little late to this and I'm confused. I have some
> >questions?
> >> >> 1) Does CLANG9 imply CLANGPE?
> >> >> 2) Does CLANGPE work on Linux and macOS? Can you pass the Windows
> >style arguments to CLANGPE linker on Linux and macOS?
> >> >> 3) For the EmulatorPkg don't you have the extra requirement that
> >compiler needs a standard C lib (or platform specific libs) to function?
> >> >>       a) GCC:*_CLANG9_*_DLINK_FLAGS in EmulatorPkg.dsc seems to
> >imply the Linux and macOS systems will have a Windows SKD dir and a lot of
> >Windows DLLs? Does all that come when you install CLANG9 when you install
> >it on Linux or macOS?
> >> >>
> >> >>
> >> >>
> >> >> So I guess I'm asking is the linker really the same for CLANG9 on all
> >systems? I guess the answer could be yes, but it seems the C lib for the Host
> >App is still an App for that OS and is OS dependent?
> >> >>
> >> >>
> >> >>
> >> >> Sorry if I'm missing something fundamental and this is a dumb question.
> >> >>
> >> >>
> >> >>
> >> >> Thanks,
> >> >>
> >> >>
> >> >>
> >> >> Andrew Fish
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On Oct 17, 2019, at 12:27 AM, Ni, Ray
> ><ray.ni@intel.com<mailto:ray.ni@intel.com>> wrote:
> >> >>
> >> >> Liming,
> >> >> Emulator is using a generic SEC module. The host specific module is called
> >"Host".
> >> >> So I prefer to change the macro to "WIN_HOST_BUILD", with this change,
> >Reviewed-by: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> >> >>
> >> >>
> >> >>
> >> >> -----Original Message-----
> >> >> From: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> >> >> Sent: Thursday, October 17, 2019 2:56 PM
> >> >> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> >> >> Cc: Justen, Jordan L
> ><jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>; Andrew
> >Fish
> >> >> <afish@apple.com<mailto:afish@apple.com>>; Ni, Ray
> ><ray.ni@intel.com<mailto:ray.ni@intel.com>>
> >> >> Subject: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
> >> >>
> >> >> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
> >> >> 1. Add WIN_SEC_BUILD macro check for CLANG9 tool chain build -p
> >> >> EmulatorPkg\EmulatorPkg.dsc -a IA32 -DWIN_SEC_BUILD=TRUE -t
> >CLANG9
> >> >> build -p EmulatorPkg\EmulatorPkg.dsc -a X64 -DWIN_SEC_BUILD=TRUE -t
> >> >> CLANG9 2. Append CLANG CC and LINK flags to generate windows HOST.
> >> >> 3. Fix WinHost issue to call GetProcessAffinityMask() API.
> >> >>  The input parameter should be UINTN pointer instead of UINT32 pointer.
> >> >>
> >> >> Cc: Jordan Justen
> ><jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>
> >> >> Cc: Andrew Fish <afish@apple.com<mailto:afish@apple.com>>
> >> >> Cc: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> >> >> Signed-off-by: Liming Gao
> ><liming.gao@intel.com<mailto:liming.gao@intel.com>>
> >> >> ---
> >> >> EmulatorPkg/Win/Host/WinHost.c   | 6 +++---
> >> >> EmulatorPkg/EmulatorPkg.dsc      | 7 ++++++-
> >> >> EmulatorPkg/Win/Host/WinHost.inf | 6 ++++++
> >> >> 3 files changed, 15 insertions(+), 4 deletions(-)
> >> >>
> >> >> diff --git a/EmulatorPkg/Win/Host/WinHost.c
> >> >> b/EmulatorPkg/Win/Host/WinHost.c index 9aba3c8959..e40ce32548
> >100644
> >> >> --- a/EmulatorPkg/Win/Host/WinHost.c
> >> >> +++ b/EmulatorPkg/Win/Host/WinHost.c
> >> >> @@ -356,7 +356,7 @@ Returns:
> >> >> INTN
> >> >> EFIAPI
> >> >> main (
> >> >> -  IN  INTN  Argc,
> >> >> +  IN  INT  Argc,
> >> >>  IN  CHAR8 **Argv,
> >> >>  IN  CHAR8 **Envp
> >> >>  )
> >> >> @@ -391,8 +391,8 @@ Returns:
> >> >>  VOID                  *SecFile;
> >> >>  CHAR16                *MemorySizeStr;
> >> >>  CHAR16                *FirmwareVolumesStr;
> >> >> -  UINT32                ProcessAffinityMask;
> >> >> -  UINT32                SystemAffinityMask;
> >> >> +  UINTN                 ProcessAffinityMask;
> >> >> +  UINTN                 SystemAffinityMask;
> >> >>  INT32                 LowBit;
> >> >>
> >> >>  //
> >> >> diff --git a/EmulatorPkg/EmulatorPkg.dsc
> >b/EmulatorPkg/EmulatorPkg.dsc
> >> >> index 20f1187713..72532f5daf 100644
> >> >> --- a/EmulatorPkg/EmulatorPkg.dsc
> >> >> +++ b/EmulatorPkg/EmulatorPkg.dsc
> >> >> @@ -237,9 +237,10 @@
> >> >>
> >> >> [Components]
> >> >> !if "IA32" in $(ARCH) || "X64" in $(ARCH)
> >> >> -  !if "MSFT" in $(FAMILY)
> >> >> +  !if "MSFT" in $(FAMILY) || $(WIN_SEC_BUILD) == TRUE
> >> >>    ##
> >> >>    #  Emulator, OS WIN application
> >> >> +    #  CLANG9 is cross OS tool chain. It depends on WIN_SEC_BUILD
> >macro.
> >> >>    ##
> >> >>    EmulatorPkg/Win/Host/WinHost.inf
> >> >>  !else
> >> >> @@ -419,7 +420,11 @@
> >> >>
> >> >>  MSFT:DEBUG_*_*_CC_FLAGS = /Od /Oy-
> >> >>  MSFT:NOOPT_*_*_CC_FLAGS = /Od /Oy-
> >> >> +  GCC:DEBUG_CLANG9_*_CC_FLAGS =-O0 -Wno-unused-command-
> >line-
> >> >> argument
> >> >> + -Wno-incompatible-pointer-types -Wno-enum-conversion
> >> >> + -Wno-incompatible-pointer-types -Wno-sometimes-uninitialized
> >> >> + -Wno-constant-conversion -Wno-main-return-type
> >> >>
> >> >>  MSFT:*_*_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
> >> >> /SUBSYSTEM:CONSOLE
> >> >>  MSFT:DEBUG_*_*_DLINK_FLAGS =
> >> >> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> >> >>  MSFT:NOOPT_*_*_DLINK_FLAGS =
> >> >> /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> >> >> +  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
> >> >> /SUBSYSTEM:CONSOLE
> >> >> +  GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
> >> >> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> >> >> + GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
> >> >> + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> >> >> diff --git a/EmulatorPkg/Win/Host/WinHost.inf
> >> >> b/EmulatorPkg/Win/Host/WinHost.inf
> >> >> index 631d5a6470..1adca10d79 100644
> >> >> --- a/EmulatorPkg/Win/Host/WinHost.inf
> >> >> +++ b/EmulatorPkg/Win/Host/WinHost.inf
> >> >> @@ -95,3 +95,9 @@
> >> >>  MSFT:*_VS2017_X64_DLINK_FLAGS      =
> >> >> /LIBPATH:"%VCToolsInstallDir%lib\x64"
> >> >> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
> >> >> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
> >> >> /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP
> >> >> /OPT:REF /DEBUG /MACHINE:AMD64 /LTCG Kernel32.lib MSVCRTD.lib
> >> >> vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib Winmm.lib Advapi32.lib
> >> >>  MSFT:*_*_X64_ASM_FLAGS            == /nologo /W3 /WX /c /Cx /Zd /W0
> >/Zi
> >> >>  MSFT:*_*_X64_ASMLINK_FLAGS        == /link /nologo
> >> >> +
> >> >> +  GCC:*_CLANG9_X64_DLINK_FLAGS ==
> >> >> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
> >> >> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> >> >> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
> >> >> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
> >> >> /LIBPATH:"%VCToolsInstallDir%lib\x64"   /NOLOGO
> >/SUBSYSTEM:CONSOLE
> >> >> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:AMD64
> >> >> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
> >> >> Winmm.lib Advapi32.lib /lldmap
> >> >> /EXPORT:InitializeDriver=_ModuleEntryPoint
> >> >> +  GCC:*_CLANG9_X64_CC_FLAGS == -m64 -g -fshort-wchar
> >> >> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
> >> >> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D
> >UNICODE
> >> >> -D
> >> >> + _CRT_SECURE_NO_DEPRECATE
> >> >> +
> >> >> +  GCC:*_CLANG9_IA32_DLINK_FLAGS ==
> >> >> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
> >> >> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> >> >> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86"
> >> >> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86"
> >> >> /LIBPATH:"%VCToolsInstallDir%ib\x86"   /NOLOGO
> >/SUBSYSTEM:CONSOLE
> >> >> /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:I386
> >> >> Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
> >> >> Winmm.lib Advapi32.lib /lldmap
> >> >> /EXPORT:InitializeDriver=_ModuleEntryPoint
> >> >> +  GCC:*_CLANG9_IA32_CC_FLAGS == -m32 -g -fshort-wchar
> >> >> + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
> >> >> + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D
> >UNICODE
> >> >> -D
> >> >> + _CRT_SECURE_NO_DEPRECATE
> >> >> --
> >> >> 2.13.0.windows.1
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >>
> >
> >
> 

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

[Leif Lindholm]

Hi Liming,

I don't feel we can release the stable tag with the toolchain
profile still holding this name. Do you have any comments?

Best Regards,

Leif

On Fri, Oct 25, 2019 at 11:45:10AM -0700, Andrew Fish via Groups.Io wrote:
> Liming,
> 
> Sorry I missed this mail. Thanks for the info! I was doing some
> research into this too and now I think I finally understand. I think
> the name for the tool chain really confused me and we should think
> about changing the name.
> 
> From what I understand CLANG9 means produce PE/COFF directly and
> used the PDB debugging format. I see from the llvm site that the
> linker can produce PDB directly as you mention. This all makes sense
> to me now as LLVM tries to make it easy to be a drop in replacement
> for VC++ or GCC. So this tool chain is designed to be able to cross
> build a "Windows App" on a Linux or macOS. It also looks like the
> llvm debugger, lldb, is lagging in its support for PDB based
> debugging.
> 
> Anyway I think Leif and I agree the toolchain name is very
> confusing. I'd rather see it called CLANG9_WIN or CLANG_PDB.
> 
> > On Oct 18, 2019, at 7:27 AM, Liming Gao <liming.gao@intel.com> wrote:
> > 
> > Andrew:
> >  Here is the cover letter on CLANG9 introduction. https://edk2.groups.io/g/devel/message/49157 <https://edk2.groups.io/g/devel/message/49157>
> >
> > 1)      Yes. CLANG9 tool chain is added to directly generate PE/COFF image (EFI image).
> > This tool chain uses LLVM clang C compiler and lld linker, generates PE/COFF
> > image and PDB compatible debug symbol format. Now, it supports IA32/X64 Archs.
> > LLVM clang C compiler and lld linker are the standalone tool set. They don’t depend other lib to generate PE/COFF image.
> >
> > 2)      Yes. CLANG9 is the cross OS tool chain. It can work on Windows/Linux/Mac host OS.
> > LLVM LLD linker uses Windows style arguments. I verify CLANG9 for Ovmf3264 in Windows/Linux host OS.
> >
> 
> On Linux can you source level debug Ovmf? 
> 
> > 3)     This patch enables WinHost in Windows. It doesn’t enable UnixHost. Now, EmulatorPkg with CLANG9 only works on Windows Host.
> > This patch can make other modules pass build in Windows/Linux/Mac only if LLVM9 tool set is installed.
> > But, the generated image may not work on Linux/Mac. I agree below linker flags are specific to windows host.
> > So, I suggest to add the conditional statement of $(WIN_HOST_BUILD) == TRUE for them.
> >
> 
> For the EmulatorPkg the Host is a native App for that OS you build on, but it seems like CLANG9 is targeted to build Windows Apps. I'm not sure  but you might be able to override all the linker commands to build a native app, or just use the system linker for the Host?
> 
> I'm not sure how well debugging will work mixing PDB and DWARF symbol formats? 
> 
> Thanks,
> 
> Andrew Fish
> 
> 
> > !if $(WIN_HOST_BUILD) == TRUE
> >   GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096 /SUBSYSTEM:CONSOLE
> >   GCC:DEBUG_CLANG9_*_DLINK_FLAGS = /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> >   GCC:NOOPT_CLANG9_*_DLINK_FLAGS = /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> > !endif
> >
> > Thanks
> > Liming
> >  <>From: afish@apple.com <afish@apple.com> 
> > Sent: Friday, October 18, 2019 1:15 AM
> > To: Ni, Ray <ray.ni@intel.com>
> > Cc: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io; Justen, Jordan L <jordan.l.justen@intel.com>
> > Subject: Re: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
> >
> > Ray,
> >
> > Sorry I'm coming a little late to this and I'm confused. I have some questions?
> > 1) Does CLANG9 imply CLANGPE? 
> > 2) Does CLANGPE work on Linux and macOS? Can you pass the Windows style arguments to CLANGPE linker on Linux and macOS?
> > 3) For the EmulatorPkg don't you have the extra requirement that compiler needs a standard C lib (or platform specific libs) to function?
> >        a) GCC:*_CLANG9_*_DLINK_FLAGS in EmulatorPkg.dsc seems to imply the Linux and macOS systems will have a Windows SKD dir and a lot of Windows DLLs? Does all that come when you install CLANG9 when you install it on Linux or macOS?
> > 
> > 
> > So I guess I'm asking is the linker really the same for CLANG9 on all systems? I guess the answer could be yes, but it seems the C lib for the Host App is still an App for that OS and is OS dependent? 
> > 
> > 
> > Sorry if I'm missing something fundamental and this is a dumb question. 
> > 
> > 
> > Thanks,
> > 
> > 
> > Andrew Fish
> > 
> >
> >
> > 
> > 
> > On Oct 17, 2019, at 12:27 AM, Ni, Ray <ray.ni@intel.com <mailto:ray.ni@intel.com>> wrote:
> >
> > Liming,
> > Emulator is using a generic SEC module. The host specific module is called "Host".
> > So I prefer to change the macro to "WIN_HOST_BUILD", with this change, Reviewed-by: Ray Ni <ray.ni@intel.com <mailto:ray.ni@intel.com>>
> > 
> > 
> > -----Original Message-----
> > From: Gao, Liming <liming.gao@intel.com <mailto:liming.gao@intel.com>>
> > Sent: Thursday, October 17, 2019 2:56 PM
> > To: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> > Cc: Justen, Jordan L <jordan.l.justen@intel.com <mailto:jordan.l.justen@intel.com>>; Andrew Fish
> > <afish@apple.com <mailto:afish@apple.com>>; Ni, Ray <ray.ni@intel.com <mailto:ray.ni@intel.com>>
> > Subject: [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain
> > 
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603 <https://bugzilla.tianocore.org/show_bug.cgi?id=1603>
> > 1. Add WIN_SEC_BUILD macro check for CLANG9 tool chain build -p
> > EmulatorPkg\EmulatorPkg.dsc -a IA32 -DWIN_SEC_BUILD=TRUE -t CLANG9
> > build -p EmulatorPkg\EmulatorPkg.dsc -a X64 -DWIN_SEC_BUILD=TRUE -t
> > CLANG9 2. Append CLANG CC and LINK flags to generate windows HOST.
> > 3. Fix WinHost issue to call GetProcessAffinityMask() API.
> >   The input parameter should be UINTN pointer instead of UINT32 pointer.
> > 
> > Cc: Jordan Justen <jordan.l.justen@intel.com <mailto:jordan.l.justen@intel.com>>
> > Cc: Andrew Fish <afish@apple.com <mailto:afish@apple.com>>
> > Cc: Ray Ni <ray.ni@intel.com <mailto:ray.ni@intel.com>>
> > Signed-off-by: Liming Gao <liming.gao@intel.com <mailto:liming.gao@intel.com>>
> > ---
> > EmulatorPkg/Win/Host/WinHost.c   | 6 +++---
> > EmulatorPkg/EmulatorPkg.dsc      | 7 ++++++-
> > EmulatorPkg/Win/Host/WinHost.inf | 6 ++++++
> > 3 files changed, 15 insertions(+), 4 deletions(-)
> > 
> > diff --git a/EmulatorPkg/Win/Host/WinHost.c
> > b/EmulatorPkg/Win/Host/WinHost.c index 9aba3c8959..e40ce32548 100644
> > --- a/EmulatorPkg/Win/Host/WinHost.c
> > +++ b/EmulatorPkg/Win/Host/WinHost.c
> > @@ -356,7 +356,7 @@ Returns:
> > INTN
> > EFIAPI
> > main (
> > -  IN  INTN  Argc,
> > +  IN  INT  Argc,
> >   IN  CHAR8 **Argv,
> >   IN  CHAR8 **Envp
> >   )
> > @@ -391,8 +391,8 @@ Returns:
> >   VOID                  *SecFile;
> >   CHAR16                *MemorySizeStr;
> >   CHAR16                *FirmwareVolumesStr;
> > -  UINT32                ProcessAffinityMask;
> > -  UINT32                SystemAffinityMask;
> > +  UINTN                 ProcessAffinityMask;
> > +  UINTN                 SystemAffinityMask;
> >   INT32                 LowBit;
> > 
> >   //
> > diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
> > index 20f1187713..72532f5daf 100644
> > --- a/EmulatorPkg/EmulatorPkg.dsc
> > +++ b/EmulatorPkg/EmulatorPkg.dsc
> > @@ -237,9 +237,10 @@
> > 
> > [Components]
> > !if "IA32" in $(ARCH) || "X64" in $(ARCH)
> > -  !if "MSFT" in $(FAMILY)
> > +  !if "MSFT" in $(FAMILY) || $(WIN_SEC_BUILD) == TRUE
> >     ##
> >     #  Emulator, OS WIN application
> > +    #  CLANG9 is cross OS tool chain. It depends on WIN_SEC_BUILD macro.
> >     ##
> >     EmulatorPkg/Win/Host/WinHost.inf
> >   !else
> > @@ -419,7 +420,11 @@
> > 
> >   MSFT:DEBUG_*_*_CC_FLAGS = /Od /Oy-
> >   MSFT:NOOPT_*_*_CC_FLAGS = /Od /Oy-
> > +  GCC:DEBUG_CLANG9_*_CC_FLAGS =-O0 -Wno-unused-command-line-
> > argument
> > + -Wno-incompatible-pointer-types -Wno-enum-conversion
> > + -Wno-incompatible-pointer-types -Wno-sometimes-uninitialized
> > + -Wno-constant-conversion -Wno-main-return-type
> > 
> >   MSFT:*_*_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
> > /SUBSYSTEM:CONSOLE
> >   MSFT:DEBUG_*_*_DLINK_FLAGS =
> > /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> >   MSFT:NOOPT_*_*_DLINK_FLAGS =
> > /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> > +  GCC:*_CLANG9_*_DLINK_FLAGS     = /ALIGN:4096 /FILEALIGN:4096
> > /SUBSYSTEM:CONSOLE
> > +  GCC:DEBUG_CLANG9_*_DLINK_FLAGS =
> > + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> > + GCC:NOOPT_CLANG9_*_DLINK_FLAGS =
> > + /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000
> > diff --git a/EmulatorPkg/Win/Host/WinHost.inf
> > b/EmulatorPkg/Win/Host/WinHost.inf
> > index 631d5a6470..1adca10d79 100644
> > --- a/EmulatorPkg/Win/Host/WinHost.inf
> > +++ b/EmulatorPkg/Win/Host/WinHost.inf
> > @@ -95,3 +95,9 @@
> >   MSFT:*_VS2017_X64_DLINK_FLAGS      =
> > /LIBPATH:"%VCToolsInstallDir%lib\x64"
> > /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
> > /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
> > /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP
> > /OPT:REF /DEBUG /MACHINE:AMD64 /LTCG Kernel32.lib MSVCRTD.lib
> > vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib Winmm.lib Advapi32.lib
> >   MSFT:*_*_X64_ASM_FLAGS            == /nologo /W3 /WX /c /Cx /Zd /W0 /Zi
> >   MSFT:*_*_X64_ASMLINK_FLAGS        == /link /nologo
> > +
> > +  GCC:*_CLANG9_X64_DLINK_FLAGS ==
> > /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
> > /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> > /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64"
> > /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64"
> > /LIBPATH:"%VCToolsInstallDir%lib\x64"   /NOLOGO /SUBSYSTEM:CONSOLE
> > /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:AMD64
> > Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
> > Winmm.lib Advapi32.lib /lldmap
> > /EXPORT:InitializeDriver=_ModuleEntryPoint
> > +  GCC:*_CLANG9_X64_CC_FLAGS == -m64 -g -fshort-wchar
> > + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
> > + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D UNICODE
> > -D
> > + _CRT_SECURE_NO_DEPRECATE
> > +
> > +  GCC:*_CLANG9_IA32_DLINK_FLAGS ==
> > /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x10000000
> > /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> > /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86"
> > /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86"
> > /LIBPATH:"%VCToolsInstallDir%ib\x86"   /NOLOGO /SUBSYSTEM:CONSOLE
> > /NODEFAULTLIB /IGNORE:4086  /OPT:REF /DEBUG /MACHINE:I386
> > Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib User32.lib
> > Winmm.lib Advapi32.lib /lldmap
> > /EXPORT:InitializeDriver=_ModuleEntryPoint
> > +  GCC:*_CLANG9_IA32_CC_FLAGS == -m32 -g -fshort-wchar
> > + -fno-strict-aliasing -Wall -c -include AutoGen.h -D
> > + _CRT_SECURE_NO_WARNINGS -Wnonportable-include-path  -D UNICODE
> > -D
> > + _CRT_SECURE_NO_DEPRECATE
> > --
> > 2.13.0.windows.1
> >
> >
> > 
> 
> 
> 
> 

[Patch v3 11/11] OvmfPkg: Enable CLANG9 tool chain

[Liming Gao]

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
1. Apply CLANG9 Linker option.
2. Exclude -mno-mmx -mno-sse compiler option for CLANG9
These two options will cause CLANG Linker crush.

Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
---
 OvmfPkg/OvmfPkgIa32.dsc    | 4 +++-
 OvmfPkg/OvmfPkgIa32X64.dsc | 4 +++-
 OvmfPkg/OvmfPkgX64.dsc     | 4 +++-
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 66e944436a..0fde8e6e84 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -66,7 +66,7 @@
   GCC:RELEASE_*_*_CC_FLAGS             = -DMDEPKG_NDEBUG
   INTEL:RELEASE_*_*_CC_FLAGS           = /D MDEPKG_NDEBUG
   MSFT:RELEASE_*_*_CC_FLAGS            = /D MDEPKG_NDEBUG
-!if $(TOOL_CHAIN_TAG) != "XCODE5"
+!if $(TOOL_CHAIN_TAG) != "XCODE5" && $(TOOL_CHAIN_TAG) != "CLANG9"
   GCC:*_*_*_CC_FLAGS                   = -mno-mmx -mno-sse
 !endif
 
@@ -80,12 +80,14 @@
 [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
   GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
   XCODE:*_*_*_DLINK_FLAGS =
+  CLANGPE: *_*_*_DLINK_FLAGS = /ALIGN:4096
 
 # 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
   XCODE:*_*_*_DLINK_FLAGS =
+  CLANGPE: *_*_*_DLINK_FLAGS = /ALIGN:4096
 
 ################################################################################
 #
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 51c2bfb44f..c17329878e 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -66,7 +66,7 @@
   GCC:RELEASE_*_*_CC_FLAGS             = -DMDEPKG_NDEBUG
   INTEL:RELEASE_*_*_CC_FLAGS           = /D MDEPKG_NDEBUG
   MSFT:RELEASE_*_*_CC_FLAGS            = /D MDEPKG_NDEBUG
-!if $(TOOL_CHAIN_TAG) != "XCODE5"
+!if $(TOOL_CHAIN_TAG) != "XCODE5" && $(TOOL_CHAIN_TAG) != "CLANG9"
   GCC:*_*_*_CC_FLAGS                   = -mno-mmx -mno-sse
 !endif
 !ifdef $(SOURCE_DEBUG_ENABLE)
@@ -85,12 +85,14 @@
 [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
   GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
   XCODE:*_*_*_DLINK_FLAGS =
+  CLANGPE: *_*_*_DLINK_FLAGS = /ALIGN:4096
 
 # 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
   XCODE:*_*_*_DLINK_FLAGS =
+  CLANGPE: *_*_*_DLINK_FLAGS = /ALIGN:4096
 
 ################################################################################
 #
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index ba7a758844..af91265d05 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -66,7 +66,7 @@
   GCC:RELEASE_*_*_CC_FLAGS             = -DMDEPKG_NDEBUG
   INTEL:RELEASE_*_*_CC_FLAGS           = /D MDEPKG_NDEBUG
   MSFT:RELEASE_*_*_CC_FLAGS            = /D MDEPKG_NDEBUG
-!if $(TOOL_CHAIN_TAG) != "XCODE5"
+!if $(TOOL_CHAIN_TAG) != "XCODE5" && $(TOOL_CHAIN_TAG) != "CLANG9"
   GCC:*_*_*_CC_FLAGS                   = -mno-mmx -mno-sse
 !endif
 !ifdef $(SOURCE_DEBUG_ENABLE)
@@ -85,12 +85,14 @@
 [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
   GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
   XCODE:*_*_*_DLINK_FLAGS =
+  CLANGPE: *_*_*_DLINK_FLAGS = /ALIGN:4096
 
 # 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
   XCODE:*_*_*_DLINK_FLAGS =
+  CLANGPE: *_*_*_DLINK_FLAGS = /ALIGN:4096
 
 ################################################################################
 #
-- 
2.13.0.windows.1

Re: [edk2-devel] [Patch v3 00/11] New Cross OS tool chain CLANG9

[Leif Lindholm]

Hi Liming,

I had missed that this set was out for review (I would appreciate a cc
on any future revisions).

On Thu, Oct 17, 2019 at 02:55:44PM +0800, Liming Gao wrote:
> In v3, add the detail commit message for patch 3. 
> Update the fix in EmulatorPkg based on the comments.
> 
> In v2, drop patch 12, and update commit message for 5 & 11.
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
> Code: https://github.com/lgao4/edk2/tree/CLANG9

This branch does not appear to have been updated since 5 September, so
it does not contain the version of the code sent out in this set. (And
I can find no other obvious branch in that repository that may hold
it.) Could you push an updated one please?

One thing that strikes me as problematic with the version on the
branch is that the set imports bits from GCC48 *and* GCC5. That seems
like a maintenance hazard, but may no longer be the case for the
current version of the set?

Best Regards,

Leif

> Wiki: https://github.com/lgao4/edk2/wiki/CLANG9-Tools-Chain
> 
> CLANG9 tool chain is added to directly generate PE/COFF image (EFI image).
> This tool chain uses LLVM clang C compiler and lld linker, generates PE/COFF
> image and PDB compatible debug symbol format. Now, it supports IA32/X64 Archs.
> It must use LLVM 9 or above release. LLVM 9 is ready on 
> http://releases.llvm.org/download.html#9.0.0.
> 
> CLANG9 is the cross OS tool chain. It can work on Windows/Linux/Mac host OS. 
> For the same source code, with the same version LLVM tool chain, 
> CLANG9 can generate the same binary image. So, the developer can 
> choose the different development environment and work on the same 
> code base. Besides, EDKII project build also requires third party 
> tools: nasm and iasl. They both keep the same version. If so, the same 
> binary image can be generated on the different host OS.
> 
> LLVM tool chain provides the compiler and linker. To build EDK2 project, 
> some other tools are still required. On Windows OS, nmake and Visual Studio 
> are required to call Makefile and compile BaseTools C tools. 
> On Linux/Mac, binutils and gcc are required to make and compile BaseTools 
> C tools. Because VS or GCC are mainly used to compile BaseTools and provide 
> nmake/make tool, they can keep on the stable version without update.
> 
> To build source code, CLANG9 tool chain (-t CLANG9) can be specified
> on Windows OS, set CLANG_HOST_BIN=n, set CLANG9_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 CLANG9_BIN=C:\Program Files\LLVM\bin\
> *  set IASL_PREFIX=C:\Asl\
> 
> On Linux/Mac, export CLANG9_BIN=LLVM installed directory, CLANG_HOST_BIN is 
> not required, because there is no prefix for make.
> For example:
> *  export CLANG9_BIN=/home/clang9/bin/
> 
> Now, CLANG9 tool chain has been verified in Edk2 packages and Ovmf/Emulator
> with LLVM 9.0.0 on Windows and Linux OS. 
> OVMF IA32/X64/IA32X64 all boots to Shell on Windows and Linux OS. 
> Emulator can boot to Shell on Windows only with CLANG9.
> OVMF Ia32X64 RELEASE build generates the same BIOS images on Windows and Linux OS.
> 
> Cc: Jiewen Yao <jiewen.yao@intel.com>
> Cc: Steven Shi <steven.shi@intel.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Laszlo Ersek <lersek@redhat.com>
> Cc: Andrew Fish <afish@apple.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Jian J Wang <jian.j.wang@intel.com>
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: Bob Feng <bob.c.feng@intel.com>
> Cc: Michael D Kinney <michael.d.kinney@intel.com>
> 
> Liming Gao (11):
>   BaseTools tools_def.template: Remove unnecessary $(DEST_DIR_DEBUG)
>     path
>   BaseTools tools_def: Add CLANG9 tool chain to directly generate PE
>     image
>   BaseTools GenFw: Fix the issue to update the wrong size as SectionSize
>   MdePkg Base.h: Add definition for CLANG9 tool chain
>   MdePkg BaseIoLibIntrinsic: Remove __inline__ attribute for IO
>     functions
>   MdeModulePkg LzmaCustomDecompressLib: Update macro to be same in CLANG
>     tool
>   MdeModulePkg RegularExpressionDxe: Disable warning for CLANG9 tool
>     chain
>   CryptoPkg: Append options to make CLANG9 tool chain pass build
>   CryptoPkg IntrinsicLib: Make _fltused always be used
>   EmulatorPkg: Enable CLANG9 tool chain
>   OvmfPkg: Enable CLANG9 tool chain
> 
>  BaseTools/Source/C/GenFw/GenFw.c                   |   8 +-
>  CryptoPkg/Library/IntrinsicLib/MemoryIntrinsics.c  |  10 +-
>  EmulatorPkg/Win/Host/WinHost.c                     |   6 +-
>  MdePkg/Library/BaseIoLibIntrinsic/IoLibGcc.c       |   6 -
>  BaseTools/Conf/build_rule.template                 |  26 +++--
>  BaseTools/Conf/tools_def.template                  | 124 +++++++++++++++++++--
>  CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf    |   1 +
>  CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf     |   1 +
>  CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf |   1 +
>  CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf     |   1 +
>  CryptoPkg/Library/OpensslLib/OpensslLib.inf        |   1 +
>  CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf  |   1 +
>  EmulatorPkg/EmulatorPkg.dsc                        |   7 +-
>  EmulatorPkg/Win/Host/WinHost.inf                   |   6 +
>  .../LzmaCustomDecompressLib/Sdk/C/7zTypes.h        |   2 +-
>  .../RegularExpressionDxe/RegularExpressionDxe.inf  |   3 +
>  MdePkg/Include/Base.h                              |   6 +-
>  MdePkg/Include/Ia32/ProcessorBind.h                |   4 +-
>  MdePkg/Include/X64/ProcessorBind.h                 |   2 +-
>  OvmfPkg/OvmfPkgIa32.dsc                            |   4 +-
>  OvmfPkg/OvmfPkgIa32X64.dsc                         |   4 +-
>  OvmfPkg/OvmfPkgX64.dsc                             |   4 +-
>  22 files changed, 183 insertions(+), 45 deletions(-)
> 
> -- 
> 2.13.0.windows.1
> 
> 
> 
> 

Re: [edk2-devel] [Patch v3 00/11] New Cross OS tool chain CLANG9

[Liming Gao]

Leif:

>-----Original Message-----
>From: Leif Lindholm [mailto:leif.lindholm@linaro.org]
>Sent: Friday, October 18, 2019 12:31 AM
>To: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>
>Cc: Yao, Jiewen <jiewen.yao@intel.com>; Shi, Steven
><steven.shi@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>; Laszlo
>Ersek <lersek@redhat.com>; Andrew Fish <afish@apple.com>; Ni, Ray
><ray.ni@intel.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>; Wang, Jian
>J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Feng, Bob C
><bob.c.feng@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>
>Subject: Re: [edk2-devel] [Patch v3 00/11] New Cross OS tool chain CLANG9
>
>Hi Liming,
>
>I had missed that this set was out for review (I would appreciate a cc
>on any future revisions).
Yes. 

>
>On Thu, Oct 17, 2019 at 02:55:44PM +0800, Liming Gao wrote:
>> In v3, add the detail commit message for patch 3.
>> Update the fix in EmulatorPkg based on the comments.
>>
>> In v2, drop patch 12, and update commit message for 5 & 11.
>>
>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
>> Code: https://github.com/lgao4/edk2/tree/CLANG9
>
>This branch does not appear to have been updated since 5 September, so
>it does not contain the version of the code sent out in this set. (And
>I can find no other obvious branch in that repository that may hold
>it.) Could you push an updated one please?
>
Done
Code: https://github.com/lgao4/edk2/tree/CLANG9_v3

>One thing that strikes me as problematic with the version on the
>branch is that the set imports bits from GCC48 *and* GCC5. That seems
>like a maintenance hazard, but may no longer be the case for the
>current version of the set?
>
CLANG9 tool chain refers to CLANG38 tool chain. So, it refers to GCC48 and GCC5 flags.
1. CLANG9 CC flags reuses GCC48_ALL_CC_FLAGS. GCC48_ALL_CC_FLAGS is common GCC flags 
for GCC48, GCC49, GCC5 and CLANG38. So, I think it is fine to reuse it in new CLANG9 tool chain. 
2. CLANG9 ASM_FLAGS reuses GCC5_ASM_FLAGS. It is same to common GCC_ASM_FLAGS. I 
Can use GCC_ASM_FLAGS. 

Thanks
Liming
>Best Regards,
>
>Leif
>
>> Wiki: https://github.com/lgao4/edk2/wiki/CLANG9-Tools-Chain
>>
>> CLANG9 tool chain is added to directly generate PE/COFF image (EFI image).
>> This tool chain uses LLVM clang C compiler and lld linker, generates PE/COFF
>> image and PDB compatible debug symbol format. Now, it supports IA32/X64
>Archs.
>> It must use LLVM 9 or above release. LLVM 9 is ready on
>> http://releases.llvm.org/download.html#9.0.0.
>>
>> CLANG9 is the cross OS tool chain. It can work on Windows/Linux/Mac host
>OS.
>> For the same source code, with the same version LLVM tool chain,
>> CLANG9 can generate the same binary image. So, the developer can
>> choose the different development environment and work on the same
>> code base. Besides, EDKII project build also requires third party
>> tools: nasm and iasl. They both keep the same version. If so, the same
>> binary image can be generated on the different host OS.
>>
>> LLVM tool chain provides the compiler and linker. To build EDK2 project,
>> some other tools are still required. On Windows OS, nmake and Visual
>Studio
>> are required to call Makefile and compile BaseTools C tools.
>> On Linux/Mac, binutils and gcc are required to make and compile BaseTools
>> C tools. Because VS or GCC are mainly used to compile BaseTools and
>provide
>> nmake/make tool, they can keep on the stable version without update.
>>
>> To build source code, CLANG9 tool chain (-t CLANG9) can be specified
>> on Windows OS, set CLANG_HOST_BIN=n, set CLANG9_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 CLANG9_BIN=C:\Program Files\LLVM\bin\
>> *  set IASL_PREFIX=C:\Asl\
>>
>> On Linux/Mac, export CLANG9_BIN=LLVM installed directory,
>CLANG_HOST_BIN is
>> not required, because there is no prefix for make.
>> For example:
>> *  export CLANG9_BIN=/home/clang9/bin/
>>
>> Now, CLANG9 tool chain has been verified in Edk2 packages and
>Ovmf/Emulator
>> with LLVM 9.0.0 on Windows and Linux OS.
>> OVMF IA32/X64/IA32X64 all boots to Shell on Windows and Linux OS.
>> Emulator can boot to Shell on Windows only with CLANG9.
>> OVMF Ia32X64 RELEASE build generates the same BIOS images on Windows
>and Linux OS.
>>
>> Cc: Jiewen Yao <jiewen.yao@intel.com>
>> Cc: Steven Shi <steven.shi@intel.com>
>> Cc: Jordan Justen <jordan.l.justen@intel.com>
>> Cc: Laszlo Ersek <lersek@redhat.com>
>> Cc: Andrew Fish <afish@apple.com>
>> Cc: Ray Ni <ray.ni@intel.com>
>> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Cc: Jian J Wang <jian.j.wang@intel.com>
>> Cc: Hao A Wu <hao.a.wu@intel.com>
>> Cc: Bob Feng <bob.c.feng@intel.com>
>> Cc: Michael D Kinney <michael.d.kinney@intel.com>
>>
>> Liming Gao (11):
>>   BaseTools tools_def.template: Remove unnecessary $(DEST_DIR_DEBUG)
>>     path
>>   BaseTools tools_def: Add CLANG9 tool chain to directly generate PE
>>     image
>>   BaseTools GenFw: Fix the issue to update the wrong size as SectionSize
>>   MdePkg Base.h: Add definition for CLANG9 tool chain
>>   MdePkg BaseIoLibIntrinsic: Remove __inline__ attribute for IO
>>     functions
>>   MdeModulePkg LzmaCustomDecompressLib: Update macro to be same in
>CLANG
>>     tool
>>   MdeModulePkg RegularExpressionDxe: Disable warning for CLANG9 tool
>>     chain
>>   CryptoPkg: Append options to make CLANG9 tool chain pass build
>>   CryptoPkg IntrinsicLib: Make _fltused always be used
>>   EmulatorPkg: Enable CLANG9 tool chain
>>   OvmfPkg: Enable CLANG9 tool chain
>>
>>  BaseTools/Source/C/GenFw/GenFw.c                   |   8 +-
>>  CryptoPkg/Library/IntrinsicLib/MemoryIntrinsics.c  |  10 +-
>>  EmulatorPkg/Win/Host/WinHost.c                     |   6 +-
>>  MdePkg/Library/BaseIoLibIntrinsic/IoLibGcc.c       |   6 -
>>  BaseTools/Conf/build_rule.template                 |  26 +++--
>>  BaseTools/Conf/tools_def.template                  | 124
>+++++++++++++++++++--
>>  CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf    |   1 +
>>  CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf     |   1 +
>>  CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf |   1 +
>>  CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf     |   1 +
>>  CryptoPkg/Library/OpensslLib/OpensslLib.inf        |   1 +
>>  CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf  |   1 +
>>  EmulatorPkg/EmulatorPkg.dsc                        |   7 +-
>>  EmulatorPkg/Win/Host/WinHost.inf                   |   6 +
>>  .../LzmaCustomDecompressLib/Sdk/C/7zTypes.h        |   2 +-
>>  .../RegularExpressionDxe/RegularExpressionDxe.inf  |   3 +
>>  MdePkg/Include/Base.h                              |   6 +-
>>  MdePkg/Include/Ia32/ProcessorBind.h                |   4 +-
>>  MdePkg/Include/X64/ProcessorBind.h                 |   2 +-
>>  OvmfPkg/OvmfPkgIa32.dsc                            |   4 +-
>>  OvmfPkg/OvmfPkgIa32X64.dsc                         |   4 +-
>>  OvmfPkg/OvmfPkgX64.dsc                             |   4 +-
>>  22 files changed, 183 insertions(+), 45 deletions(-)
>>
>> --
>> 2.13.0.windows.1
>>
>>
>> 
>>