[PATCH 0/3] BaseTools GCC: pass CC flags to linker

[PATCH 0/3] BaseTools GCC: pass CC flags to linker

[Ard Biesheuvel]

GCC5 runs in LTO mode, which means it may generate code during the link
stage, and this code generation should be subject to the same settings
as ordinary code generation.

Since we now invoke GCC as the linker, we can start passing the CC_FLAGS
to the linker as well, with only minor surgery. This does not bother
non-LTO links at all, and forces the LTO links to use the correct settings.

Ard Biesheuvel (3):
  BaseTools GCC: move -c compiler flag to build rules
  BaseTools GCC5: disable warnings-as-errors for now
  BaseTools GCC: add the compiler flags to the linker command line

 BaseTools/Conf/build_rule.template | 18 ++++++++++--------
 BaseTools/Conf/tools_def.template  | 18 +++++++++---------
 2 files changed, 19 insertions(+), 17 deletions(-)

-- 
2.7.4

[PATCH 1/3] BaseTools GCC: move -c compiler flag to build rules

[Ard Biesheuvel]

In order to be able to share the compiler flags with the linker (which
is required for LTO since it involves the linker doing code generation
based on the LTO bytecode), move the -c GCC argument to the build rules,
and drop it from the GCC CC_FLAGS definitions in tools_def.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 BaseTools/Conf/build_rule.template | 16 +++++++++-------
 BaseTools/Conf/tools_def.template  | 10 +++++-----
 2 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/BaseTools/Conf/build_rule.template b/BaseTools/Conf/build_rule.template
index 9adf3918e42e..7d9f8ca075c2 100644
--- a/BaseTools/Conf/build_rule.template
+++ b/BaseTools/Conf/build_rule.template
@@ -130,7 +130,10 @@
     <Command.MSFT, Command.INTEL>
         "$(CC)" /Fo${dst} $(CC_FLAGS) $(INC) ${src}
 
-    <Command.GCC, Command.GCCLD, Command.RVCT>
+    <Command.GCC, Command.GCCLD>
+        "$(CC)" $(CC_FLAGS) -c -o ${dst} $(INC) ${src}
+
+    <Command.RVCT>
         # For RVCTCYGWIN CC_FLAGS must be first to work around pathing issues
         "$(CC)" $(CC_FLAGS) -o ${dst} $(INC) ${src}
 
@@ -156,9 +159,8 @@
     <Command.MSFT, Command.INTEL>
         "$(CC)" /Fo${dst} $(CC_FLAGS) $(INC) ${src}
 
-    <Command.GCC, Command.GCCLD, Command.RVCT>
-        # For RVCTCYGWIN CC_FLAGS must be first to work around pathing issues
-        "$(CC)" $(CC_FLAGS) -o ${dst} $(INC) ${src}
+    <Command.GCC, Command.GCCLD>
+        "$(CC)" $(CC_FLAGS) -c -o ${dst} $(INC) ${src}
         "$(SYMRENAME)" $(SYMRENAME_FLAGS) ${dst}
 
 [C-Code-File.BASE.AARCH64,C-Code-File.SEC.AARCH64,C-Code-File.PEI_CORE.AARCH64,C-Code-File.PEIM.AARCH64]
@@ -172,7 +174,7 @@
         $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
 
     <Command.GCC, Command.GCCLD>
-        "$(CC)" $(CC_FLAGS) $(CC_XIPFLAGS) -o ${dst} $(INC) ${src}
+        "$(CC)" $(CC_FLAGS) $(CC_XIPFLAGS) -c -o ${dst} $(INC) ${src}
 
 [C-Header-File]
     <InputFile>
@@ -446,7 +448,7 @@
         "$(GENFW)" -o ${dst} -c $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll $(GENFW_FLAGS)
 
     <Command.GCC, Command.GCCLD>
-        "$(ASLCC)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj $(CC_FLAGS) $(ASLCC_FLAGS) $(INC) ${src}
+        "$(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
         "$(GENFW)" -o ${dst} -c $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll $(GENFW_FLAGS)
 
@@ -466,7 +468,7 @@
         "$(GENFW)" -o ${dst} -c $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll $(GENFW_FLAGS)
 
     <Command.GCC, Command.GCCLD>
-        "$(ASLCC)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj $(CC_FLAGS) $(ASLCC_FLAGS) $(INC) ${src}
+        "$(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
         "$(GENFW)" -o ${dst} -c $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll $(GENFW_FLAGS)
         
diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template
index fd9eccb9b92a..289e75cc3be6 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -4330,7 +4330,7 @@ NOOPT_DDK3790xASL_IPF_DLINK_FLAGS    = /NOLOGO /NODEFAULTLIB /LTCG /DLL /OPT:REF
 DEBUG_*_*_OBJCOPY_ADDDEBUGFLAG     = --add-gnu-debuglink=$(DEBUG_DIR)/$(MODULE_NAME).debug
 RELEASE_*_*_OBJCOPY_ADDDEBUGFLAG   =
 
-DEFINE GCC_ALL_CC_FLAGS            = -g -Os -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -c -include AutoGen.h -fno-common
+DEFINE GCC_ALL_CC_FLAGS            = -g -Os -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -include AutoGen.h -fno-common
 DEFINE GCC_IA32_CC_FLAGS           = DEF(GCC_ALL_CC_FLAGS) -m32 -malign-double -freorder-blocks -freorder-blocks-and-partition -O2 -mno-stack-arg-probe
 DEFINE GCC_X64_CC_FLAGS            = DEF(GCC_ALL_CC_FLAGS) -mno-red-zone -Wno-address -mno-stack-arg-probe
 DEFINE GCC_IPF_CC_FLAGS            = DEF(GCC_ALL_CC_FLAGS) -minline-int-divide-min-latency
@@ -4362,7 +4362,7 @@ DEFINE GCC_IPF_RC_FLAGS            = -I binary -O elf64-ia64-little   -B ia64
 DEFINE GCC_ARM_RC_FLAGS            = -I binary -O elf32-littlearm     -B arm     --rename-section .data=.hii
 DEFINE GCC_AARCH64_RC_FLAGS        = -I binary -O elf64-littleaarch64 -B aarch64 --rename-section .data=.hii
 
-DEFINE GCC44_ALL_CC_FLAGS            = -g -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -ffunction-sections -fdata-sections -c -include AutoGen.h -fno-common -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
+DEFINE GCC44_ALL_CC_FLAGS            = -g -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -ffunction-sections -fdata-sections -include AutoGen.h -fno-common -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
 DEFINE GCC44_IA32_CC_FLAGS           = DEF(GCC44_ALL_CC_FLAGS) -m32 -march=i586 -malign-double -fno-stack-protector -D EFI32 -fno-asynchronous-unwind-tables
 DEFINE GCC44_X64_CC_FLAGS            = DEF(GCC44_ALL_CC_FLAGS) -m64 -fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" -Os -maccumulate-outgoing-args -mno-red-zone -Wno-address -mcmodel=small -fpie -fno-asynchronous-unwind-tables
 DEFINE GCC44_IA32_X64_DLINK_COMMON   = -nostdlib -Wl,-n,-q,--gc-sections -z common-page-size=0x20
@@ -5677,7 +5677,7 @@ RELEASE_CLANG35_AARCH64_CC_FLAGS = DEF(CLANG35_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS)
 *_ELFGCC_IA32_ASLDLINK_PATH         = DEF(ELFGCC_BIN)/ld
 *_ELFGCC_IA32_RC_PATH               = DEF(ELFGCC_BIN)/objcopy
 
-*_ELFGCC_IA32_CC_FLAGS              = -m32 -g -fshort-wchar -fno-strict-aliasing -Wall -malign-double -c -include $(DEST_DIR_DEBUG)/AutoGen.h -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
+*_ELFGCC_IA32_CC_FLAGS              = -m32 -g -fshort-wchar -fno-strict-aliasing -Wall -malign-double -include $(DEST_DIR_DEBUG)/AutoGen.h -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
 *_ELFGCC_IA32_SLINK_FLAGS           =
 *_ELFGCC_IA32_DLINK_FLAGS           = -melf_i386 -nostdlib --shared --entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map
 #*_ELFGCC_IA32_DLINK_FLAGS          = -melf_i386 -nostdlib -n -q -Ttext 0x220 --entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT)
@@ -5702,7 +5702,7 @@ RELEASE_CLANG35_AARCH64_CC_FLAGS = DEF(CLANG35_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS)
 *_ELFGCC_X64_VFRPP_PATH            = DEF(ELFGCC_BIN)/gcc
 *_ELFGCC_X64_RC_PATH               = DEF(ELFGCC_BIN)/objcopy
 
-*_ELFGCC_X64_CC_FLAGS              = -Os -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-address -Wno-array-bounds -c -include AutoGen.h -D_EFI_P64
+*_ELFGCC_X64_CC_FLAGS              = -Os -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-address -Wno-array-bounds -include AutoGen.h -D_EFI_P64
 *_ELFGCC_X64_DLINK_FLAGS           = -nostdlib --shared --entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map
 *_ELFGCC_X64_SLINK_FLAGS           =
 *_ELFGCC_X64_ASM_FLAGS             = -c -x assembler -imacros $(DEST_DIR_DEBUG)/AutoGen.h
@@ -5725,7 +5725,7 @@ RELEASE_CLANG35_AARCH64_CC_FLAGS = DEF(CLANG35_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS)
 *_ELFGCC_IPF_VFRPP_PATH           = DEF(ELFGCC_BIN)/gcc
 *_ELFGCC_IPF_RC_PATH              = DEF(ELFGCC_BIN)/objcopy
 
-*_ELFGCC_IPF_CC_FLAGS             = -Os -fshort-wchar -Wall -Werror -c -include AutoGen.h -D_EFI_P64
+*_ELFGCC_IPF_CC_FLAGS             = -Os -fshort-wchar -Wall -Werror -include AutoGen.h -D_EFI_P64
 *_ELFGCC_IPF_DLINK_FLAGS          = -nostdlib --shared --entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map
 *_ELFGCC_IPF_SLINK_FLAGS          =
 *_ELFGCC_IPF_ASM_FLAGS            = -c -x assembler -imacros $(DEST_DIR_DEBUG)/AutoGen.h
-- 
2.7.4

[PATCH 2/3] BaseTools GCC5: disable warnings-as-errors for now

[Ard Biesheuvel]

GCC5 runs in LTO mode, which means it may generate code from an
intermediate representation during the link stage, at which time
additional diagnostics are run that may emit warnings.

Some of these warnings seem to be spurious, e.g., the following
warning which is emitted when building OVMF for IA32 or ArmVirtQemu
for ARM (but not for X64 resp. AARCH64)

  .../MdeModulePkg/Library/UefiHiiLib/HiiLib.c:
                 In function 'HiiCreateGuidOpCode.constprop':
  .../MdeModulePkg/Library/UefiHiiLib/HiiLib.c:3228:10:
                 error: function may return address of local variable
                                            [-Werror=return-local-addr]
     return (UINT8 *)OpCodePointer;
            ^
  .../MdeModulePkg/Library/UefiHiiLib/HiiLib.c:3208:17: note: declared here
     EFI_IFR_GUID  OpCode;
                   ^
  lto1: all warnings being treated as errors
  lto-wrapper: fatal error: gcc returned 1 exit status

So before adding the contents of CC_FLAGS to the linker command line,
defuse the default '-Werror' by adding '-Wno-error' to DLINK2_FLAGS
for GCC5.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 BaseTools/Conf/tools_def.template | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template
index 289e75cc3be6..1f55740929d7 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -4466,9 +4466,9 @@ DEFINE GCC5_X64_CC_FLAGS             = DEF(GCC49_X64_CC_FLAGS) -flto -fno-builti
 DEFINE GCC5_IA32_X64_DLINK_COMMON    = DEF(GCC49_IA32_X64_DLINK_COMMON)
 DEFINE GCC5_IA32_X64_ASLDLINK_FLAGS  = DEF(GCC49_IA32_X64_ASLDLINK_FLAGS)
 DEFINE GCC5_IA32_X64_DLINK_FLAGS     = DEF(GCC49_IA32_X64_DLINK_FLAGS) -flto
-DEFINE GCC5_IA32_DLINK2_FLAGS        = DEF(GCC49_IA32_DLINK2_FLAGS)
+DEFINE GCC5_IA32_DLINK2_FLAGS        = DEF(GCC49_IA32_DLINK2_FLAGS) -Wno-error
 DEFINE GCC5_X64_DLINK_FLAGS          = DEF(GCC49_X64_DLINK_FLAGS) -flto
-DEFINE GCC5_X64_DLINK2_FLAGS         = DEF(GCC49_X64_DLINK2_FLAGS)
+DEFINE GCC5_X64_DLINK2_FLAGS         = DEF(GCC49_X64_DLINK2_FLAGS) -Wno-error
 DEFINE GCC5_ASM_FLAGS                = DEF(GCC49_ASM_FLAGS)
 DEFINE GCC5_ARM_ASM_FLAGS            = DEF(GCC49_ARM_ASM_FLAGS)
 DEFINE GCC5_AARCH64_ASM_FLAGS        = DEF(GCC49_AARCH64_ASM_FLAGS)
@@ -4476,9 +4476,9 @@ DEFINE GCC5_ARM_CC_FLAGS             = DEF(GCC49_ARM_CC_FLAGS)
 DEFINE GCC5_AARCH64_CC_FLAGS         = DEF(GCC49_AARCH64_CC_FLAGS)
 DEFINE GCC5_AARCH64_CC_XIPFLAGS      = DEF(GCC49_AARCH64_CC_XIPFLAGS)
 DEFINE GCC5_ARM_DLINK_FLAGS          = DEF(GCC49_ARM_DLINK_FLAGS)
-DEFINE GCC5_ARM_DLINK2_FLAGS         = DEF(GCC49_ARM_DLINK2_FLAGS)
+DEFINE GCC5_ARM_DLINK2_FLAGS         = DEF(GCC49_ARM_DLINK2_FLAGS) -Wno-error
 DEFINE GCC5_AARCH64_DLINK_FLAGS      = DEF(GCC49_AARCH64_DLINK_FLAGS)
-DEFINE GCC5_AARCH64_DLINK2_FLAGS     = DEF(GCC49_AARCH64_DLINK2_FLAGS)
+DEFINE GCC5_AARCH64_DLINK2_FLAGS     = DEF(GCC49_AARCH64_DLINK2_FLAGS) -Wno-error
 DEFINE GCC5_ARM_ASLDLINK_FLAGS       = DEF(GCC49_ARM_ASLDLINK_FLAGS)
 DEFINE GCC5_AARCH64_ASLDLINK_FLAGS   = DEF(GCC49_AARCH64_ASLDLINK_FLAGS)
 
-- 
2.7.4

[PATCH 3/3] BaseTools GCC: add the compiler flags to the linker command line

[Ard Biesheuvel]

Now that we invoke GCC as the linker for the GCC toolchain family,
we can pass the CC flags to the linker as well. This is only
required for LTO (which may involve code generation during the link
stage), but does not interfere with non-LTO builds.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 BaseTools/Conf/build_rule.template | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Conf/build_rule.template b/BaseTools/Conf/build_rule.template
index 7d9f8ca075c2..ddeef59a9ec6 100644
--- a/BaseTools/Conf/build_rule.template
+++ b/BaseTools/Conf/build_rule.template
@@ -294,7 +294,7 @@
         "$(DLINK)" /OUT:${dst} $(DLINK_FLAGS) $(DLINK_SPATH) @$(STATIC_LIBRARY_FILES_LIST)
 
     <Command.GCC>
-        "$(DLINK)" -o ${dst} $(DLINK_FLAGS) -Wl,--start-group,@$(STATIC_LIBRARY_FILES_LIST),--end-group $(DLINK2_FLAGS)
+        "$(DLINK)" -o ${dst} $(DLINK_FLAGS) -Wl,--start-group,@$(STATIC_LIBRARY_FILES_LIST),--end-group $(CC_FLAGS) $(DLINK2_FLAGS)
         "$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
 
     <Command.GCCLD>
-- 
2.7.4

Re: [PATCH 0/3] BaseTools GCC: pass CC flags to linker

[Gao, Liming]

Ard:
  Without this change, GCC5 LTO can pass build. With it, what difference will be in the generated image? Original way may generate the wrong image, or new way will generate the smaller image? 

Thanks
Liming
-----Original Message-----
From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] 
Sent: Tuesday, August 2, 2016 10:39 PM
To: Zhu, Yonghong <yonghong.zhu@intel.com>; Gao, Liming <liming.gao@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>; edk2-devel@lists.01.org; leif.lindholm@linaro.org
Cc: sigmaepsilon92@gmail.com; Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: [PATCH 0/3] BaseTools GCC: pass CC flags to linker

GCC5 runs in LTO mode, which means it may generate code during the link
stage, and this code generation should be subject to the same settings
as ordinary code generation.

Since we now invoke GCC as the linker, we can start passing the CC_FLAGS
to the linker as well, with only minor surgery. This does not bother
non-LTO links at all, and forces the LTO links to use the correct settings.

Ard Biesheuvel (3):
  BaseTools GCC: move -c compiler flag to build rules
  BaseTools GCC5: disable warnings-as-errors for now
  BaseTools GCC: add the compiler flags to the linker command line

 BaseTools/Conf/build_rule.template | 18 ++++++++++--------
 BaseTools/Conf/tools_def.template  | 18 +++++++++---------
 2 files changed, 19 insertions(+), 17 deletions(-)

-- 
2.7.4

Re: [PATCH 0/3] BaseTools GCC: pass CC flags to linker

[Ard Biesheuvel]

On 2 August 2016 at 16:50, Gao, Liming <liming.gao@intel.com> wrote:
> Ard:
>   Without this change, GCC5 LTO can pass build. With it, what difference will be in the generated image? Original way may generate the wrong image, or new way will generate the smaller image?
>

This is not about code size but about correctness. Compiler switches
for code model or alignment etc may affect the way code is generated
at link time by the LTO routines.

Re: [PATCH 1/3] BaseTools GCC: move -c compiler flag to build rules

[Leif Lindholm]

On Tue, Aug 02, 2016 at 04:39:30PM +0200, Ard Biesheuvel wrote:
> In order to be able to share the compiler flags with the linker (which
> is required for LTO since it involves the linker doing code generation
> based on the LTO bytecode), move the -c GCC argument to the build rules,
> and drop it from the GCC CC_FLAGS definitions in tools_def.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>  BaseTools/Conf/build_rule.template | 16 +++++++++-------
>  BaseTools/Conf/tools_def.template  | 10 +++++-----
>  2 files changed, 14 insertions(+), 12 deletions(-)
> 
> diff --git a/BaseTools/Conf/build_rule.template b/BaseTools/Conf/build_rule.template
> index 9adf3918e42e..7d9f8ca075c2 100644
> --- a/BaseTools/Conf/build_rule.template
> +++ b/BaseTools/Conf/build_rule.template
> @@ -130,7 +130,10 @@
>      <Command.MSFT, Command.INTEL>
>          "$(CC)" /Fo${dst} $(CC_FLAGS) $(INC) ${src}
>  
> -    <Command.GCC, Command.GCCLD, Command.RVCT>
> +    <Command.GCC, Command.GCCLD>
> +        "$(CC)" $(CC_FLAGS) -c -o ${dst} $(INC) ${src}
> +
> +    <Command.RVCT>

Apart from the slightly larger patch set, is there any reason not to
split out the RVCT handling here and fix up tools_def.template for it
too?

/
    Leif

>          # For RVCTCYGWIN CC_FLAGS must be first to work around pathing issues
>          "$(CC)" $(CC_FLAGS) -o ${dst} $(INC) ${src}
>  
> @@ -156,9 +159,8 @@
>      <Command.MSFT, Command.INTEL>
>          "$(CC)" /Fo${dst} $(CC_FLAGS) $(INC) ${src}
>  
> -    <Command.GCC, Command.GCCLD, Command.RVCT>
> -        # For RVCTCYGWIN CC_FLAGS must be first to work around pathing issues
> -        "$(CC)" $(CC_FLAGS) -o ${dst} $(INC) ${src}
> +    <Command.GCC, Command.GCCLD>
> +        "$(CC)" $(CC_FLAGS) -c -o ${dst} $(INC) ${src}
>          "$(SYMRENAME)" $(SYMRENAME_FLAGS) ${dst}
>  
>  [C-Code-File.BASE.AARCH64,C-Code-File.SEC.AARCH64,C-Code-File.PEI_CORE.AARCH64,C-Code-File.PEIM.AARCH64]
> @@ -172,7 +174,7 @@
>          $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
>  
>      <Command.GCC, Command.GCCLD>
> -        "$(CC)" $(CC_FLAGS) $(CC_XIPFLAGS) -o ${dst} $(INC) ${src}
> +        "$(CC)" $(CC_FLAGS) $(CC_XIPFLAGS) -c -o ${dst} $(INC) ${src}
>  
>  [C-Header-File]
>      <InputFile>
> @@ -446,7 +448,7 @@
>          "$(GENFW)" -o ${dst} -c $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll $(GENFW_FLAGS)
>  
>      <Command.GCC, Command.GCCLD>
> -        "$(ASLCC)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj $(CC_FLAGS) $(ASLCC_FLAGS) $(INC) ${src}
> +        "$(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
>          "$(GENFW)" -o ${dst} -c $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll $(GENFW_FLAGS)
>  
> @@ -466,7 +468,7 @@
>          "$(GENFW)" -o ${dst} -c $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll $(GENFW_FLAGS)
>  
>      <Command.GCC, Command.GCCLD>
> -        "$(ASLCC)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj $(CC_FLAGS) $(ASLCC_FLAGS) $(INC) ${src}
> +        "$(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
>          "$(GENFW)" -o ${dst} -c $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll $(GENFW_FLAGS)
>          
> diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template
> index fd9eccb9b92a..289e75cc3be6 100644
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -4330,7 +4330,7 @@ NOOPT_DDK3790xASL_IPF_DLINK_FLAGS    = /NOLOGO /NODEFAULTLIB /LTCG /DLL /OPT:REF
>  DEBUG_*_*_OBJCOPY_ADDDEBUGFLAG     = --add-gnu-debuglink=$(DEBUG_DIR)/$(MODULE_NAME).debug
>  RELEASE_*_*_OBJCOPY_ADDDEBUGFLAG   =
>  
> -DEFINE GCC_ALL_CC_FLAGS            = -g -Os -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -c -include AutoGen.h -fno-common
> +DEFINE GCC_ALL_CC_FLAGS            = -g -Os -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -include AutoGen.h -fno-common
>  DEFINE GCC_IA32_CC_FLAGS           = DEF(GCC_ALL_CC_FLAGS) -m32 -malign-double -freorder-blocks -freorder-blocks-and-partition -O2 -mno-stack-arg-probe
>  DEFINE GCC_X64_CC_FLAGS            = DEF(GCC_ALL_CC_FLAGS) -mno-red-zone -Wno-address -mno-stack-arg-probe
>  DEFINE GCC_IPF_CC_FLAGS            = DEF(GCC_ALL_CC_FLAGS) -minline-int-divide-min-latency
> @@ -4362,7 +4362,7 @@ DEFINE GCC_IPF_RC_FLAGS            = -I binary -O elf64-ia64-little   -B ia64
>  DEFINE GCC_ARM_RC_FLAGS            = -I binary -O elf32-littlearm     -B arm     --rename-section .data=.hii
>  DEFINE GCC_AARCH64_RC_FLAGS        = -I binary -O elf64-littleaarch64 -B aarch64 --rename-section .data=.hii
>  
> -DEFINE GCC44_ALL_CC_FLAGS            = -g -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -ffunction-sections -fdata-sections -c -include AutoGen.h -fno-common -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
> +DEFINE GCC44_ALL_CC_FLAGS            = -g -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -ffunction-sections -fdata-sections -include AutoGen.h -fno-common -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
>  DEFINE GCC44_IA32_CC_FLAGS           = DEF(GCC44_ALL_CC_FLAGS) -m32 -march=i586 -malign-double -fno-stack-protector -D EFI32 -fno-asynchronous-unwind-tables
>  DEFINE GCC44_X64_CC_FLAGS            = DEF(GCC44_ALL_CC_FLAGS) -m64 -fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" -Os -maccumulate-outgoing-args -mno-red-zone -Wno-address -mcmodel=small -fpie -fno-asynchronous-unwind-tables
>  DEFINE GCC44_IA32_X64_DLINK_COMMON   = -nostdlib -Wl,-n,-q,--gc-sections -z common-page-size=0x20
> @@ -5677,7 +5677,7 @@ RELEASE_CLANG35_AARCH64_CC_FLAGS = DEF(CLANG35_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS)
>  *_ELFGCC_IA32_ASLDLINK_PATH         = DEF(ELFGCC_BIN)/ld
>  *_ELFGCC_IA32_RC_PATH               = DEF(ELFGCC_BIN)/objcopy
>  
> -*_ELFGCC_IA32_CC_FLAGS              = -m32 -g -fshort-wchar -fno-strict-aliasing -Wall -malign-double -c -include $(DEST_DIR_DEBUG)/AutoGen.h -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
> +*_ELFGCC_IA32_CC_FLAGS              = -m32 -g -fshort-wchar -fno-strict-aliasing -Wall -malign-double -include $(DEST_DIR_DEBUG)/AutoGen.h -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
>  *_ELFGCC_IA32_SLINK_FLAGS           =
>  *_ELFGCC_IA32_DLINK_FLAGS           = -melf_i386 -nostdlib --shared --entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map
>  #*_ELFGCC_IA32_DLINK_FLAGS          = -melf_i386 -nostdlib -n -q -Ttext 0x220 --entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT)
> @@ -5702,7 +5702,7 @@ RELEASE_CLANG35_AARCH64_CC_FLAGS = DEF(CLANG35_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS)
>  *_ELFGCC_X64_VFRPP_PATH            = DEF(ELFGCC_BIN)/gcc
>  *_ELFGCC_X64_RC_PATH               = DEF(ELFGCC_BIN)/objcopy
>  
> -*_ELFGCC_X64_CC_FLAGS              = -Os -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-address -Wno-array-bounds -c -include AutoGen.h -D_EFI_P64
> +*_ELFGCC_X64_CC_FLAGS              = -Os -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-address -Wno-array-bounds -include AutoGen.h -D_EFI_P64
>  *_ELFGCC_X64_DLINK_FLAGS           = -nostdlib --shared --entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map
>  *_ELFGCC_X64_SLINK_FLAGS           =
>  *_ELFGCC_X64_ASM_FLAGS             = -c -x assembler -imacros $(DEST_DIR_DEBUG)/AutoGen.h
> @@ -5725,7 +5725,7 @@ RELEASE_CLANG35_AARCH64_CC_FLAGS = DEF(CLANG35_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS)
>  *_ELFGCC_IPF_VFRPP_PATH           = DEF(ELFGCC_BIN)/gcc
>  *_ELFGCC_IPF_RC_PATH              = DEF(ELFGCC_BIN)/objcopy
>  
> -*_ELFGCC_IPF_CC_FLAGS             = -Os -fshort-wchar -Wall -Werror -c -include AutoGen.h -D_EFI_P64
> +*_ELFGCC_IPF_CC_FLAGS             = -Os -fshort-wchar -Wall -Werror -include AutoGen.h -D_EFI_P64
>  *_ELFGCC_IPF_DLINK_FLAGS          = -nostdlib --shared --entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map
>  *_ELFGCC_IPF_SLINK_FLAGS          =
>  *_ELFGCC_IPF_ASM_FLAGS            = -c -x assembler -imacros $(DEST_DIR_DEBUG)/AutoGen.h
> -- 
> 2.7.4
> 

Re: [PATCH 1/3] BaseTools GCC: move -c compiler flag to build rules

[Ard Biesheuvel]

On 2 August 2016 at 17:01, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> On Tue, Aug 02, 2016 at 04:39:30PM +0200, Ard Biesheuvel wrote:
>> In order to be able to share the compiler flags with the linker (which
>> is required for LTO since it involves the linker doing code generation
>> based on the LTO bytecode), move the -c GCC argument to the build rules,
>> and drop it from the GCC CC_FLAGS definitions in tools_def.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>>  BaseTools/Conf/build_rule.template | 16 +++++++++-------
>>  BaseTools/Conf/tools_def.template  | 10 +++++-----
>>  2 files changed, 14 insertions(+), 12 deletions(-)
>>
>> diff --git a/BaseTools/Conf/build_rule.template b/BaseTools/Conf/build_rule.template
>> index 9adf3918e42e..7d9f8ca075c2 100644
>> --- a/BaseTools/Conf/build_rule.template
>> +++ b/BaseTools/Conf/build_rule.template
>> @@ -130,7 +130,10 @@
>>      <Command.MSFT, Command.INTEL>
>>          "$(CC)" /Fo${dst} $(CC_FLAGS) $(INC) ${src}
>>
>> -    <Command.GCC, Command.GCCLD, Command.RVCT>
>> +    <Command.GCC, Command.GCCLD>
>> +        "$(CC)" $(CC_FLAGS) -c -o ${dst} $(INC) ${src}
>> +
>> +    <Command.RVCT>
>
> Apart from the slightly larger patch set, is there any reason not to
> split out the RVCT handling here and fix up tools_def.template for it
> too?
>

In what sense do we need to fix up tools_def for RVCT?

Re: [PATCH 1/3] BaseTools GCC: move -c compiler flag to build rules

[Ard Biesheuvel]

On 2 August 2016 at 17:02, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 2 August 2016 at 17:01, Leif Lindholm <leif.lindholm@linaro.org> wrote:
>> On Tue, Aug 02, 2016 at 04:39:30PM +0200, Ard Biesheuvel wrote:
>>> In order to be able to share the compiler flags with the linker (which
>>> is required for LTO since it involves the linker doing code generation
>>> based on the LTO bytecode), move the -c GCC argument to the build rules,
>>> and drop it from the GCC CC_FLAGS definitions in tools_def.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>> ---
>>>  BaseTools/Conf/build_rule.template | 16 +++++++++-------
>>>  BaseTools/Conf/tools_def.template  | 10 +++++-----
>>>  2 files changed, 14 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/BaseTools/Conf/build_rule.template b/BaseTools/Conf/build_rule.template
>>> index 9adf3918e42e..7d9f8ca075c2 100644
>>> --- a/BaseTools/Conf/build_rule.template
>>> +++ b/BaseTools/Conf/build_rule.template
>>> @@ -130,7 +130,10 @@
>>>      <Command.MSFT, Command.INTEL>
>>>          "$(CC)" /Fo${dst} $(CC_FLAGS) $(INC) ${src}
>>>
>>> -    <Command.GCC, Command.GCCLD, Command.RVCT>
>>> +    <Command.GCC, Command.GCCLD>
>>> +        "$(CC)" $(CC_FLAGS) -c -o ${dst} $(INC) ${src}
>>> +
>>> +    <Command.RVCT>
>>
>> Apart from the slightly larger patch set, is there any reason not to
>> split out the RVCT handling here and fix up tools_def.template for it
>> too?
>>

OK, i get it now. That actually simplifies the patch, since I don't
need to split off RVCT in build_rules then

Re: [PATCH 0/3] BaseTools GCC: pass CC flags to linker

[Ard Biesheuvel]

On 2 August 2016 at 16:51, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 2 August 2016 at 16:50, Gao, Liming <liming.gao@intel.com> wrote:
>> Ard:
>>   Without this change, GCC5 LTO can pass build. With it, what difference will be in the generated image? Original way may generate the wrong image, or new way will generate the smaller image?
>>
>
> This is not about code size but about correctness. Compiler switches
> for code model or alignment etc may affect the way code is generated
> at link time by the LTO routines.

Note that Steven mentions a similar problem in his CLANG38 series: he
needs to pass -pie to the linker (or -fpie would be sufficient, I
suspect) to prevent the linker from using the wrong code model when
generating code from the LTO bytecode.

Thanks,
Ard.

Re: [PATCH 0/3] BaseTools GCC: pass CC flags to linker

[Gao, Liming]

Ard:
  I see Steven says it doesn't work, yet. So, I am curious what real issue is resolved by this patch?

Thanks
Liming
> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> Sent: Wednesday, August 03, 2016 4:23 PM
> To: Gao, Liming <liming.gao@intel.com>
> Cc: Zhu, Yonghong <yonghong.zhu@intel.com>; Justen, Jordan L
> <jordan.l.justen@intel.com>; edk2-devel@lists.01.org;
> leif.lindholm@linaro.org; sigmaepsilon92@gmail.com
> Subject: Re: [PATCH 0/3] BaseTools GCC: pass CC flags to linker
> 
> On 2 August 2016 at 16:51, Ard Biesheuvel <ard.biesheuvel@linaro.org>
> wrote:
> > On 2 August 2016 at 16:50, Gao, Liming <liming.gao@intel.com> wrote:
> >> Ard:
> >>   Without this change, GCC5 LTO can pass build. With it, what difference
> will be in the generated image? Original way may generate the wrong image,
> or new way will generate the smaller image?
> >>
> >
> > This is not about code size but about correctness. Compiler switches
> > for code model or alignment etc may affect the way code is generated
> > at link time by the LTO routines.
> 
> Note that Steven mentions a similar problem in his CLANG38 series: he
> needs to pass -pie to the linker (or -fpie would be sufficient, I
> suspect) to prevent the linker from using the wrong code model when
> generating code from the LTO bytecode.
> 
> Thanks,
> Ard.

Re: [PATCH 0/3] BaseTools GCC: pass CC flags to linker

[Ard Biesheuvel]

On 3 August 2016 at 10:58, Gao, Liming <liming.gao@intel.com> wrote:
> Ard:
>   I see Steven says it doesn't work, yet. So, I am curious what real issue is resolved by this patch?
>

For example, when building ArmVirtQemu for ARM, you may get warnings
(or errors when -Werror is enabled) like

lto1: warning: switch -mcpu=cortex-a15 conflicts with -march=armv7-a switch

where cortex-a15 is the target set by the platform .DSC, and armv7-a
is the default target of the compiler.
In this particular example, that does not cause any issues, since
cortex-a15 is compatible with armv7-a. However, if you are building
for ARM11, the code generation performed by the linker will generate
incompatible code unless we pass it the -mcpu=arm11 option as well.

The same applies to things like -mstrict-alignment and -mcmodel=xxx. I
suppose the same issue exists for IA32, where the -march/-mcpu options
in the platform may deviate from the compiler's default.

-- 
Ard.

Re: [PATCH 0/3] BaseTools GCC: pass CC flags to linker

[Gao, Liming]

Ard:
  Thanks for your detail explain. I understand it. I add my rb for this patch set.


Reviewed-by: Liming Gao <liming.gao@intel.com<mailto:liming.gao@intel.com>>

Thanks
Liming
From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
Sent: Wednesday, August 3, 2016 5:24 PM
To: Gao, Liming <liming.gao@intel.com>
Cc: Zhu, Yonghong <yonghong.zhu@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>; edk2-devel@lists.01.org; leif.lindholm@linaro.org; sigmaepsilon92@gmail.com
Subject: Re: [PATCH 0/3] BaseTools GCC: pass CC flags to linker

On 3 August 2016 at 10:58, Gao, Liming wrote:
> Ard:
> I see Steven says it doesn't work, yet. So, I am curious what real issue is resolved by this patch?
>

For example, when building ArmVirtQemu for ARM, you may get warnings
(or errors when -Werror is enabled) like

lto1: warning: switch -mcpu=cortex-a15 conflicts with -march=armv7-a switch

where cortex-a15 is the target set by the platform .DSC, and armv7-a
is the default target of the compiler.
In this particular example, that does not cause any issues, since
cortex-a15 is compatible with armv7-a. However, if you are building
for ARM11, the code generation performed by the linker will generate
incompatible code unless we pass it the -mcpu=arm11 option as well.

The same applies to things like -mstrict-alignment and -mcmodel=xxx. I
suppose the same issue exists for IA32, where the -march/-mcpu options
in the platform may deviate from the compiler's default.

--
Ard.

Re: [PATCH 0/3] BaseTools GCC: pass CC flags to linker

[Ard Biesheuvel]

On 3 August 2016 at 15:20, Gao, Liming <liming.gao@intel.com> wrote:
> Ard:
>
>   Thanks for your detail explain. I understand it. I add my rb for this
> patch set.
>
>
>
> Reviewed-by: Liming Gao <liming.gao@intel.com>
>

Pushed as

108c5b601860 BaseTools GCC: move -c compiler flag to build rules
f8d0b9662993 BaseTools GCC5: disable warnings-as-errors for now
478f50990a9a BaseTools GCC: add the compiler flags to the linker command line

with the simplification suggested by Leif regarding RVCT

Thanks,
Ard.

Re: [PATCH 3/3] BaseTools GCC: add the compiler flags to the linker command line

[Shi, Steven]

Hi Ard,

CLANG38 has a build failure as below for this patch. This failure is because the CLANG38 enable the LTO through LLVMgold.so linker plugin, but the LLVMgold.so plugin cannot accept the clang -Oz cc flag as build option. After CC_FLAG is added in the link rule, the LLVMgold.so plugin reports link error. LLVMgold.so only accept -O0~-O3, and you can see it in the LLVM gold plugin source code in below:



http://llvm.org/svn/llvm-project/llvm/tags/RELEASE_380/final/tools/gold/gold-plugin.cpp



                      if (opt[1] < '0' || opt[1] > '3')

line173：        message(LDPL_FATAL, "Optimization level must be between 0 and 3");



I hope to know is it mandatory to add compiler CC_FLAG in the linker rule for you? If it is mandatory, I have to introduce a new link rule for CLANG38 to remove the compiler CC_FLAG. What do you think?





"/home/jshi19/clang38/bin/clang" -o /home/jshi19/edk2-fork/Build/OvmfX64/DEBUG_CLANG38/X64/OvmfPkg/Sec/SecMain/DEBUG/SecMain.dll -nostdlib -Wl,-n,-q,--gc-sections -z common-page-size=0x40 -Wl,--entry,_ModuleEntryPoint -u _ModuleEntryPoint -Wl,-Map,/home/jshi19/edk2-fork/Build/OvmfX64/DEBUG_CLANG38/X64/OvmfPkg/Sec/SecMain/DEBUG/SecMain.map -flto -Wl,-Oz -Wl,-melf_x86_64 -Wl,--oformat=elf64-x86-64 -Wl,-pie -mcmodel=small -Wl,--start-group,@/home/jshi19/edk2-fork/Build/OvmfX64/DEBUG_CLANG38/X64/OvmfPkg/Sec/SecMain/OUTPUT/static_library_files.lst,--end-group -g -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -ffunction-sections -fdata-sections -include AutoGen.h -fno-common -DSTRING_ARRAY_NAME=SecMainStrings -Wno-empty-body -fno-stack-protector -fno-builtin -mms-bitfields -Wno-address -Wno-shift-negative-value -Wno-parentheses-equality -Wno-unknown-pragmas -Wno-tautological-constant-out-of-range-compare -Wno-incompatible-library-redeclaration -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -msoft-float -mno-implicit-float -ftrap-function=undefined_behavior_has_been_optimized_away_by_clang -funsigned-char -fno-ms-extensions -Wno-null-dereference -Wno-tautological-compare -m64 "-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone -mcmodel=small -fpie -Oz -flto -target x86_64-pc-linux-gnu -g -mno-mmx -mno-sse -Wl,--defsym=PECOFF_HEADER_SIZE=0x228 -Wl,--script=/home/jshi19/edk2-fork/BaseTools/Scripts/GccBase.lds -Wno-error -v

clang version 3.8.0 (tags/RELEASE_380/final)

Target: x86_64-pc-linux-gnu

Thread model: posix

InstalledDir: /home/jshi19/clang38/bin

Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7

Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.4

Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9

Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3

Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0

Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.0.0

Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0

Candidate multilib: .;@m64

Candidate multilib: 32;@m32

Candidate multilib: x32;@mx32

Selected multilib: .;@m64

"/usr/bin/ld" -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o /home/jshi19/edk2-fork/Build/OvmfX64/DEBUG_CLANG38/X64/OvmfPkg/Sec/SecMain/DEBUG/SecMain.dll -u _ModuleEntryPoint -L/usr/lib/gcc/x86_64-linux-gnu/5.4.0 -L/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../x86_64-linux-gnu -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../.. -L/home/jshi19/clang38/bin/../lib -L/lib -L/usr/lib -plugin /home/jshi19/clang38/bin/../lib/LLVMgold.so -plugin-opt=mcpu=x86-64 -plugin-opt=Oz -n -q --gc-sections -z common-page-size=0x40 --entry _ModuleEntryPoint -Map /home/jshi19/edk2-fork/Build/OvmfX64/DEBUG_CLANG38/X64/OvmfPkg/Sec/SecMain/DEBUG/SecMain.map -Oz -melf_x86_64 --oformat=elf64-x86-64 -pie --start-group @/home/jshi19/edk2-fork/Build/OvmfX64/DEBUG_CLANG38/X64/OvmfPkg/Sec/SecMain/OUTPUT/static_library_files.lst --end-group --defsym=PECOFF_HEADER_SIZE=0x228 --script=/home/jshi19/edk2-fork/BaseTools/Scripts/GccBase.lds

/usr/bin/ld: error: Optimization level must be between 0 and 3

clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation)







Steven Shi

Intel\SSG\STO\UEFI Firmware



Tel: +86 021-61166522

iNet: 821-6522





> -----Original Message-----

> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of

> Ard Biesheuvel

> Sent: Tuesday, August 02, 2016 10:40 PM

> To: Zhu, Yonghong <yonghong.zhu@intel.com>; Gao, Liming

> <liming.gao@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>;

> edk2-devel@lists.01.org; leif.lindholm@linaro.org

> Cc: sigmaepsilon92@gmail.com; Ard Biesheuvel <ard.biesheuvel@linaro.org>

> Subject: [edk2] [PATCH 3/3] BaseTools GCC: add the compiler flags to the

> linker command line

>

> Now that we invoke GCC as the linker for the GCC toolchain family,

> we can pass the CC flags to the linker as well. This is only

> required for LTO (which may involve code generation during the link

> stage), but does not interfere with non-LTO builds.

>

> Contributed-under: TianoCore Contribution Agreement 1.0

> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

> ---

>  BaseTools/Conf/build_rule.template | 2 +-

>  1 file changed, 1 insertion(+), 1 deletion(-)

>

> diff --git a/BaseTools/Conf/build_rule.template

> b/BaseTools/Conf/build_rule.template

> index 7d9f8ca075c2..ddeef59a9ec6 100644

> --- a/BaseTools/Conf/build_rule.template

> +++ b/BaseTools/Conf/build_rule.template

> @@ -294,7 +294,7 @@

>          "$(DLINK)" /OUT:${dst} $(DLINK_FLAGS) $(DLINK_SPATH)

> @$(STATIC_LIBRARY_FILES_LIST)

>

>      <Command.GCC>

> -        "$(DLINK)" -o ${dst} $(DLINK_FLAGS) -Wl,--start-

> group,@$(STATIC_LIBRARY_FILES_LIST),--end-group $(DLINK2_FLAGS)

> +        "$(DLINK)" -o ${dst} $(DLINK_FLAGS) -Wl,--start-

> group,@$(STATIC_LIBRARY_FILES_LIST),--end-group $(CC_FLAGS)

> $(DLINK2_FLAGS)

>          "$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}

>

>      <Command.GCCLD>

> --

> 2.7.4

>

> _______________________________________________

> edk2-devel mailing list

> edk2-devel@lists.01.org

> https://lists.01.org/mailman/listinfo/edk2-devel

Re: [PATCH 3/3] BaseTools GCC: add the compiler flags to the linker command line

[Ard Biesheuvel]

On 17 August 2016 at 13:38, Shi, Steven <steven.shi@intel.com> wrote:
> Hi Ard,
>
> CLANG38 has a build failure as below for this patch. This failure is because
> the CLANG38 enable the LTO through LLVMgold.so linker plugin, but the
> LLVMgold.so plugin cannot accept the clang -Oz cc flag as build option.
> After CC_FLAG is added in the link rule, the LLVMgold.so plugin reports link
> error. LLVMgold.so only accept -O0~-O3, and you can see it in the LLVM gold
> plugin source code in below:
>

This is interesting. I tried enabling LTO with CLANG35 for AARCH64
(using a 3.7 binary) and I did not see this problem.

>
>
> http://llvm.org/svn/llvm-project/llvm/tags/RELEASE_380/final/tools/gold/gold-plugin.cpp
>
>
>
>                       if (opt[1] < '0' || opt[1] > '3')
>
> line173：        message(LDPL_FATAL, "Optimization level must be between 0
> and 3");
>
>
>
> I hope to know is it mandatory to add compiler CC_FLAG in the linker rule
> for you? If it is mandatory, I have to introduce a new link rule for CLANG38
> to remove the compiler CC_FLAG. What do you think?
>

Yes, it is mandatory. And I consider this a bug in Clang.

For example, the mcmodel=xxx parameter *must* be passed to the linker,
since the linker generates code itself under LTO, and needs to know
for which code model it is doing so.
The same applies to -fpie and -mstrict-align (although clang also
requires the -pie linker flag to generate correct code)

Could you try putting -O2 in the DLINK2_FLAGS for Clang 38? (i.e., so
that the last -O option the linker sees is not -Oz)

-- 
Ard.

Re: [PATCH 3/3] BaseTools GCC: add the compiler flags to the linker command line

[Shi, Steven]

>

> Could you try putting -O2 in the DLINK2_FLAGS for Clang 38? (i.e., so

> that the last -O option the linker sees is not -Oz)

>

Ard,

Add -O2 or -O3 in DLINK2_FLAGS works as below, thank your suggestion!



"/home/jshi19/clang38/bin/clang" -o /home/jshi19/edk2-fork/Build/OvmfX64/RELEASE_CLANG38/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll -nostdlib -Wl,-n,-q,--gc-sections -z common-page-size=0x40 -Wl,--entry,_ModuleEntryPoint -u _ModuleEntryPoint -Wl,-Map,/home/jshi19/edk2-fork/Build/OvmfX64/RELEASE_CLANG38/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.map -flto -Wl,-Oz -Wl,-melf_x86_64 -Wl,--oformat=elf64-x86-64 -Wl,-pie -mcmodel=small -Wl,--start-group,@/home/jshi19/edk2-fork/Build/OvmfX64/RELEASE_CLANG38/X64/MdeModulePkg/Core/Dxe/DxeMain/OUTPUT/static_library_files.lst,--end-group -g -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -ffunction-sections -fdata-sections -include AutoGen.h -fno-common -DSTRING_ARRAY_NAME=DxeCoreStrings -Wno-empty-body -fno-stack-protector -fno-builtin -mms-bitfields -Wno-address -Wno-shift-negative-value -Wno-parentheses-equality -Wno-unknown-pragmas -Wno-tautological-constant-out-of-range-compare -Wno-incompatible-library-redeclaration -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -msoft-float -mno-implicit-float -ftrap-function=undefined_behavior_has_been_optimized_away_by_clang -funsigned-char -fno-ms-extensions -Wno-null-dereference -Wno-tautological-compare -m64 "-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone -mcmodel=small -fpie -Oz -flto -target x86_64-pc-linux-gnu -DMDEPKG_NDEBUG -mno-mmx -mno-sse -Wl,--defsym=PECOFF_HEADER_SIZE=0x228 -Wl,--script=/home/jshi19/edk2-fork/BaseTools/Scripts/GccBase.lds -Wno-error -O3 -v

clang version 3.8.0 (tags/RELEASE_380/final)

Target: x86_64-pc-linux-gnu

Thread model: posix

InstalledDir: /home/jshi19/clang38/bin

Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7

Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.4

Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9

Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3

Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0

Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.0.0

Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0

Candidate multilib: .;@m64

Candidate multilib: 32;@m32

Candidate multilib: x32;@mx32

Selected multilib: .;@m64

"/usr/bin/ld" -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o /home/jshi19/edk2-fork/Build/OvmfX64/RELEASE_CLANG38/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll -u _ModuleEntryPoint -L/usr/lib/gcc/x86_64-linux-gnu/5.4.0 -L/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../x86_64-linux-gnu -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../.. -L/home/jshi19/clang38/bin/../lib -L/lib -L/usr/lib -plugin /home/jshi19/clang38/bin/../lib/LLVMgold.so -plugin-opt=mcpu=x86-64 -plugin-opt=O3 -n -q --gc-sections -z common-page-size=0x40 --entry _ModuleEntryPoint -Map /home/jshi19/edk2-fork/Build/OvmfX64/RELEASE_CLANG38/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.map -Oz -melf_x86_64 --oformat=elf64-x86-64 -pie --start-group @/home/jshi19/edk2-fork/Build/OvmfX64/RELEASE_CLANG38/X64/MdeModulePkg/Core/Dxe/DxeMain/OUTPUT/static_library_files.lst --end-group --defsym=PECOFF_HEADER_SIZE=0x228 --script=/home/jshi19/edk2-fork/BaseTools/Scripts/GccBase.lds



Steven Shi

Intel\SSG\STO\UEFI Firmware



Tel: +86 021-61166522

iNet: 821-6522

Re: [PATCH 3/3] BaseTools GCC: add the compiler flags to the linker command line

[Ard Biesheuvel]

On 17 August 2016 at 14:24, Shi, Steven <steven.shi@intel.com> wrote:
>>
>
>> Could you try putting -O2 in the DLINK2_FLAGS for Clang 38? (i.e., so
>
>> that the last -O option the linker sees is not -Oz)
>
>>
>
> Ard,
>
> Add -O2 or -O3 in DLINK2_FLAGS works as below, thank your suggestion!
>

Good to know!

Thanks,
Ard.