Date   

[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 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 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


Re: [PATCH v5 0/8] BaseTools: add support for GCC5 in LTO mode

Ard Biesheuvel
 

On 2 August 2016 at 15:55, Michael Zimmermann <sigmaepsilon92@gmail.com> wrote:
btw, gcc6 seems to work fine too with these patches(it did with the GCC49
configs too on both ARM and x86/x64).
Thanks for the data points. Do you see any warnings during the build?


Re: [PATCH v5 0/8] BaseTools: add support for GCC5 in LTO mode

Michael Zimmermann
 

btw, gcc6 seems to work fine too with these patches(it did with the GCC49
configs too on both ARM and x86/x64).

Thanks
Michael

On Tue, Aug 2, 2016 at 1:42 PM, Ard Biesheuvel <ard.biesheuvel@linaro.org>
wrote:

On 2 August 2016 at 13:41, Shi, Steven <steven.shi@intel.com> wrote:
Ard,
Thank you to check in GCC5!
My pleasure. Thanks to you for the comments, discussion and review
feedback.

--
Ard.
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [patch] MdeModulePkg/FvSimpleFileSystem: fix assertions when FV is empty

Zhang, Chao B <chao.b.zhang@...>
 

Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>





Thanks & Best regards
Chao Zhang

-----Original Message-----
From: Tian, Feng
Sent: Tuesday, August 02, 2016 4:10 PM
To: Zhang, Chao B
Cc: edk2-devel@lists.01.org
Subject: [patch] MdeModulePkg/FvSimpleFileSystem: fix assertions when FV is empty

The original code will assert when dealing with those empty FVs.
The fix is used to solve this bug.

Cc: Chao Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Feng Tian <feng.tian@intel.com>
---
.../Universal/FvSimpleFileSystemDxe/FvSimpleFileSystem.c | 9 +++++++--
.../FvSimpleFileSystemDxe/FvSimpleFileSystemEntryPoint.c | 6 +++++-
2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystem.c b/MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystem.c
index c6137ac..b81110f 100644
--- a/MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystem.c
+++ b/MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystem.c
@@ -526,7 +526,10 @@ FvSimpleFileSystemOpen (
InitializeListHead (&NewFile->Link);
InsertHeadList (&Instance->FileHead, &NewFile->Link);

- NewFile->DirReadNext = FVFS_GET_FIRST_FILE_INFO (Instance);
+ NewFile->DirReadNext = NULL;
+ if (!IsListEmpty (&Instance->FileInfoHead)) {
+ NewFile->DirReadNext = FVFS_GET_FIRST_FILE_INFO (Instance);
+ }

*NewHandle = &NewFile->FileProtocol;
return EFI_SUCCESS;
@@ -821,7 +824,9 @@ FvSimpleFileSystemSetPosition (
//
// Reset directory position to first entry
//
- File->DirReadNext = FVFS_GET_FIRST_FILE_INFO (Instance);
+ if (File->DirReadNext) {
+ File->DirReadNext = FVFS_GET_FIRST_FILE_INFO (Instance);
+ }
} else if (Position == 0xFFFFFFFFFFFFFFFFull) {
File->Position = File->FvFileInfo->FileInfo.FileSize;
} else {
diff --git a/MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemEntryPoint.c b/MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemEntryPoint.c
index 7167fb9..4e6089b 100644
--- a/MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemEntryPoint.c
+++ b/MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemEntryPoint.c
@@ -223,7 +223,11 @@ FvSimpleFileSystemOpenVolume (
}
}

- Instance->Root->DirReadNext = FVFS_GET_FIRST_FILE_INFO (Instance);
+ Instance->Root->DirReadNext = NULL;
+ if (!IsListEmpty (&Instance->FileInfoHead)) {
+ Instance->Root->DirReadNext = FVFS_GET_FIRST_FILE_INFO (Instance);
+ }
+
*RootFile = &Instance->Root->FileProtocol;
return Status;
}
--
2.7.1.windows.2


Re: [PATCH] ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: deal with relaxed XIP alignment

Ard Biesheuvel
 

On 2 August 2016 at 13:35, Laszlo Ersek <lersek@redhat.com> wrote:
On 08/02/16 12:17, Ard Biesheuvel wrote:
Commit b89919ee8f8c ("BaseTools AARCH64: override XIP module linker
alignment to 32 bytes") updated the various AARCH64 toolchain definitions
to allow SEC, PEI_CORE and PEIM modules to be built with minimal alignment
requirements even when using the AArch64 small code model which normally
requires 4 KB section alignment.

This involves conversion of ADRP instructions into ADR instructions, which
can only be done reliably if the ELF and the PE/COFF sections appear at
the same offset modulo 4 KB.

The ArmVirtPrePiUniCoreRelocatable linker script did not yet take this
into account, so update it by starting the .text section at the next
appropriately aligned offset PECOFF_HEADER_SIZE bytes into the image.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---

This fixes the ArmVirtQemuKernel and ArmVirtXen platforms, which are currently
broken when using DEBUG_GCC49, DEBUG_GCC5 or *_CLANG35 (all of which received
the linker alignment treatment mentioned above)

Symptoms: many occurrences of
...
GenFw: ERROR 3000: Invalid
WriteSections64(): <../ArmVirtPrePiUniCoreRelocatable.dll> AARCH64 small
code model requires identical ELF and PE/COFF section offsets modulo 4 KB.
...

and a failed build.

ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds b/ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds
index 44df7840adfd..492a8fff380f 100644
--- a/ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds
+++ b/ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds
@@ -14,9 +14,10 @@

SECTIONS
{
- .text 0x0 : ALIGN(CONSTANT(COMMONPAGESIZE)) {
- PROVIDE(__reloc_base = .);
+ PROVIDE(__reloc_base = .);

+ . = PECOFF_HEADER_SIZE;
+ .text : ALIGN(CONSTANT(COMMONPAGESIZE)) {
*(.text .text*)
*(.got .got*)
*(.rodata .rodata*)
Acked-by: Laszlo Ersek <lersek@redhat.com>
Pushed as d54e2d6c1e68
Thanks


Re: [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code

Ard Biesheuvel
 

On 2 August 2016 at 13:40, Shi, Steven <steven.shi@intel.com> wrote:

CoffAddFixup() must be used for absolute symbol references only. These
instructions contain relative symbol references, which are
recalculated in WriteSections64().

The only absolute symbol reference is the GOT entry for 'n', and your
code (in WriteRelocations64()) calculates the address of the GOT entry
(which is always in .text BTW) and adds a fixup for it, i.e.,

+ CoffAddFixup(
+ (UINT32)(UINTN)((UINT64)
mCoffSectionsOffset[RelShdr->sh_info] + GoTPcRelPtrOffset),
+ EFI_IMAGE_REL_BASED_DIR64);

This code adds a fixup to the PE/COFF .reloc section for the GOT entry
containing the address of 'n', and the instructions perform a IP
relative load of the contents of the GOT entry to retrieve the address
of 'n'.

By adding two fixups, the PE/COFF loader will apply the load offset
twice, resulting in an incorrect value.
OK, I get your point now. Yes, the current patch could generate multiple fixups for the same GOT relocation entry. How about we introduce a simple IsDuplicatedCoffFixup() to check whether a converting fixup offset is duplicated before we use CoffAddFixup() to really add it? If it is new, we add it, otherwise just skip it.
That could work, but you have to be aware that fixups are best emitted
in the order they need to be applied in the binary, or it will become
very inefficient. (Please refer to the PE/COFF spec section that
explains the layout of the .reloc section)

What it comes down to is that relocations are grouped by target page,
and for every place in the page that requires a relocation to be
applied, a 4 bit type is emitted followed by a 12-bit offset, which is
the offset into the current page. If you emit fixups for the current
instruction, followed by one for the GOT, it will basically take two
'page switches' every time.

So it would be better to simply emit the relocations, but introduce a
sorting pass that merges all duplicates as well.

Thanks,
Ard.


Re: [PATCH v5 0/8] BaseTools: add support for GCC5 in LTO mode

Ard Biesheuvel
 

On 2 August 2016 at 13:41, Shi, Steven <steven.shi@intel.com> wrote:
Ard,
Thank you to check in GCC5!
My pleasure. Thanks to you for the comments, discussion and review feedback.

--
Ard.


Re: [PATCH v5 0/8] BaseTools: add support for GCC5 in LTO mode

Shi, Steven <steven.shi@...>
 

Ard,
Thank you to check in GCC5!


Steven Shi
Intel\SSG\STO\UEFI Firmware

Tel: +86 021-61166522
iNet: 821-6522

-----Original Message-----
From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
Sent: Tuesday, August 02, 2016 5:03 PM
To: Shi, Steven <steven.shi@intel.com>; Zhu, Yonghong
<yonghong.zhu@intel.com>; Gao, Liming <liming.gao@intel.com>; Justen,
Jordan L <jordan.l.justen@intel.com>; edk2-devel-01 <edk2-
devel@lists.01.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>; Laszlo Ersek
<lersek@redhat.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [PATCH v5 0/8] BaseTools: add support for GCC5 in LTO mode

On 1 August 2016 at 10:01, Ard Biesheuvel <ard.biesheuvel@linaro.org>
wrote:
This v5 to introduce GCC5 is now a 8 piece series, including some
preparatory cleanup patches that allow all GCC4x and CLANG35 toolchains
to switch to using 'gcc' as the linker. This allows us to get rid of
the wrapper script to marshall ld arguments in order to make them
understandable by gcc, which is fragile and likely to cause problems in
the future.

Since there appears to be a natural split between the 'legacy' GCC
toolchains UNIXGCC, ELFGCC, and CYGGCC[xASL], both in term of
supported
architectures [IA32, X64, IPF] vs [IA32, X64, ARM, AARCH64], and in
terms of maintenance, these toolchains are not moved to using 'gcc' as
the linker, and instead, a new BUILDRULEFAMILY is introduced called
GCCLD
that will retain the old behavior.

The result is that GCC5 can align much more closely with its predecessors,
making the expected maintenance burden of supporting GCC back to v4.4
much lower.

Changes since v4:
- added patch to use 'protected' visibility only for the libraries that
define the module entry points (_ModuleEntryPoint), to prevent them
from
being optimized away by the LTO routines
- added Jordan's ack/RBs
- add some extra comments to tools_def.template (#8)
Thanks all. Committed as

1c63516075b3 BaseTools CLANG35: drop problematic use-movt and save-
temps options
ff54bcdf2e4e ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: ignore .hash
and .note sections
befb3ba51502 BaseTools UNIXGCC ELFGCC CYGGCC: clone GCC build rule
family into GCCLD
a1b8baccc30b BaseTools GCC: use 'gcc' as the linker command for GCC44
and later
e1458aaded8e ArmPkg: add prebuilt glue binaries for GCC5 LTO support
7fd5d619806d BaseTools GCC: drop GNU notes section from EFI image
4a8466d4baba BaseTools GCC: introduce GCC5 toolchain to support GCC
v5.x in LTO mode

with Leif and Liming's R-b. I dropped patch #7, and instead made the
visibility pragma conditional on whether LTO is disabled.

--
Ard.


Changes since v3:
- like Steven does in his GCC5LTO patch, add -fno-builtin to IA32 and X64
CC_FLAGS; this addresses a build issue reported by Liming
- add -Os the the linker flags as well, for AARCH64 this does not seem to
make
a difference, but it is arguably correct since the LTO processing at link
time involves code generation as well
- add Laszlo's ack to #2
- new patch #6 to omit the autogenerated build-id from the PE/COFF binary

Changes since v2:
- add license headers to LTO glue files for ARM and AARCH64 (#5)
- get rid of lto-ld-wrapper script

Ard Biesheuvel (8):
BaseTools CLANG35: drop problematic use-movt and save-temps options
ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: ignore .hash and .note
sections
BaseTools UNIXGCC ELFGCC CYGGCC: clone GCC build rule family into
GCCLD
BaseTools GCC: use 'gcc' as the linker command for GCC44 and later
ArmPkg: add prebuilt glue binaries for GCC5 LTO support
BaseTools GCC: drop GNU notes section from EFI image
MdePkg GCC/X64: avoid 'hidden' visibility for module entry points
BaseTools GCC: introduce GCC5 toolchain to support GCC v5.x in LTO
mode

ArmPkg/GccLto/liblto-aarch64.a | Bin 0 -> 1016
bytes
ArmPkg/GccLto/liblto-aarch64.s | 27 ++
ArmPkg/GccLto/liblto-arm.a | Bin 0 -> 2096 bytes
ArmPkg/GccLto/liblto-arm.s | 61 ++++
ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf | 2 +-
ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds | 3 +
BaseTools/Conf/build_rule.template | 31 +-
BaseTools/Conf/tools_def.template | 350
+++++++++++++++-----
BaseTools/Scripts/GccBase.lds | 6 +
EmulatorPkg/Unix/Host/Host.inf | 6 +-
MdePkg/Include/X64/ProcessorBind.h | 9 +-
MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf | 2 +
MdePkg/Library/PeiCoreEntryPoint/PeiCoreEntryPoint.inf | 2 +
MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf | 2 +
MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf |
2 +
MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf | 2 +
16 files changed, 396 insertions(+), 109 deletions(-)
create mode 100644 ArmPkg/GccLto/liblto-aarch64.a
create mode 100644 ArmPkg/GccLto/liblto-aarch64.s
create mode 100644 ArmPkg/GccLto/liblto-arm.a
create mode 100644 ArmPkg/GccLto/liblto-arm.s

--
2.7.4


Re: [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code

Shi, Steven <steven.shi@...>
 


CoffAddFixup() must be used for absolute symbol references only. These
instructions contain relative symbol references, which are
recalculated in WriteSections64().

The only absolute symbol reference is the GOT entry for 'n', and your
code (in WriteRelocations64()) calculates the address of the GOT entry
(which is always in .text BTW) and adds a fixup for it, i.e.,

+ CoffAddFixup(
+ (UINT32)(UINTN)((UINT64)
mCoffSectionsOffset[RelShdr->sh_info] + GoTPcRelPtrOffset),
+ EFI_IMAGE_REL_BASED_DIR64);

This code adds a fixup to the PE/COFF .reloc section for the GOT entry
containing the address of 'n', and the instructions perform a IP
relative load of the contents of the GOT entry to retrieve the address
of 'n'.

By adding two fixups, the PE/COFF loader will apply the load offset
twice, resulting in an incorrect value.
OK, I get your point now. Yes, the current patch could generate multiple fixups for the same GOT relocation entry. How about we introduce a simple IsDuplicatedCoffFixup() to check whether a converting fixup offset is duplicated before we use CoffAddFixup() to really add it? If it is new, we add it, otherwise just skip it.


Re: [Patch v5 36/48] OvmfPkg: Add MpInitLib reference in DSC files.

Laszlo Ersek
 

On 08/02/16 10:59, Jeff Fan wrote:
This update is for CpuMpPei&CpuDxe consuming MP Initialize library.

Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
---
OvmfPkg/OvmfPkgIa32.dsc | 2 ++
OvmfPkg/OvmfPkgIa32X64.dsc | 2 ++
OvmfPkg/OvmfPkgX64.dsc | 2 ++
3 files changed, 6 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 8af3267..5ed39f7 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -213,6 +213,7 @@ [LibraryClasses.common.PEIM]
DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
!endif
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
+ MpInitLib|UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf

[LibraryClasses.common.DXE_CORE]
HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
@@ -292,6 +293,7 @@ [LibraryClasses.common.DXE_DRIVER]
DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
!endif
PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
+ MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf

[LibraryClasses.common.UEFI_APPLICATION]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 4bb38d0..a1fae56 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -218,6 +218,7 @@ [LibraryClasses.common.PEIM]
DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
!endif
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
+ MpInitLib|UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf

[LibraryClasses.common.DXE_CORE]
HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
@@ -297,6 +298,7 @@ [LibraryClasses.common.DXE_DRIVER]
DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
!endif
PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
+ MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf

[LibraryClasses.common.UEFI_APPLICATION]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index be3aa1f..2ec8e8c 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -218,6 +218,7 @@ [LibraryClasses.common.PEIM]
DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
!endif
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
+ MpInitLib|UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf

[LibraryClasses.common.DXE_CORE]
HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
@@ -297,6 +298,7 @@ [LibraryClasses.common.DXE_DRIVER]
DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
!endif
PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
+ MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf

[LibraryClasses.common.UEFI_APPLICATION]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
Thank you for updating your git config the way I requested :)

Reviewed-by: Laszlo Ersek <lersek@redhat.com>


Re: [PATCH] ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: deal with relaxed XIP alignment

Laszlo Ersek
 

On 08/02/16 12:17, Ard Biesheuvel wrote:
Commit b89919ee8f8c ("BaseTools AARCH64: override XIP module linker
alignment to 32 bytes") updated the various AARCH64 toolchain definitions
to allow SEC, PEI_CORE and PEIM modules to be built with minimal alignment
requirements even when using the AArch64 small code model which normally
requires 4 KB section alignment.

This involves conversion of ADRP instructions into ADR instructions, which
can only be done reliably if the ELF and the PE/COFF sections appear at
the same offset modulo 4 KB.

The ArmVirtPrePiUniCoreRelocatable linker script did not yet take this
into account, so update it by starting the .text section at the next
appropriately aligned offset PECOFF_HEADER_SIZE bytes into the image.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---

This fixes the ArmVirtQemuKernel and ArmVirtXen platforms, which are currently
broken when using DEBUG_GCC49, DEBUG_GCC5 or *_CLANG35 (all of which received
the linker alignment treatment mentioned above)

Symptoms: many occurrences of
...
GenFw: ERROR 3000: Invalid
WriteSections64(): <../ArmVirtPrePiUniCoreRelocatable.dll> AARCH64 small
code model requires identical ELF and PE/COFF section offsets modulo 4 KB.
...

and a failed build.

ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds b/ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds
index 44df7840adfd..492a8fff380f 100644
--- a/ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds
+++ b/ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds
@@ -14,9 +14,10 @@

SECTIONS
{
- .text 0x0 : ALIGN(CONSTANT(COMMONPAGESIZE)) {
- PROVIDE(__reloc_base = .);
+ PROVIDE(__reloc_base = .);

+ . = PECOFF_HEADER_SIZE;
+ .text : ALIGN(CONSTANT(COMMONPAGESIZE)) {
*(.text .text*)
*(.got .got*)
*(.rodata .rodata*)
Acked-by: Laszlo Ersek <lersek@redhat.com>


[Patch] SecurityPkg OpalPasswordDxe: Fix buffer overflow issue.

Dong, Eric
 

In current code, PSID is processed as string and the length is 0x20.
Current code only reserved 0x20 length buffer for it, no extra buffer
for the '\0'. When driver call UnicodeStrToAsciiStrS to convert PSID,
it search the '\0' for the end. So extra dirty data saved in PSID
info which caused PSID revert action failed. This patch reserved
extra 1 byte data for the '\0'.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong <eric.dong@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
---
SecurityPkg/Tcg/Opal/OpalPasswordDxe/OpalHii.c | 5 ++++-
SecurityPkg/Tcg/Opal/OpalPasswordDxe/OpalHiiFormValues.h | 3 ++-
2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/SecurityPkg/Tcg/Opal/OpalPasswordDxe/OpalHii.c b/SecurityPkg/Tcg/Opal/OpalPasswordDxe/OpalHii.c
index 9a44c56..ee73697 100644
--- a/SecurityPkg/Tcg/Opal/OpalPasswordDxe/OpalHii.c
+++ b/SecurityPkg/Tcg/Opal/OpalPasswordDxe/OpalHii.c
@@ -595,12 +595,15 @@ HiiPsidRevert(
OPAL_DISK *OpalDisk;
TCG_RESULT Ret;
OPAL_SESSION Session;
+ UINT8 TmpBuf[PSID_CHARACTER_STRING_END_LENGTH];

Ret = TcgResultFailure;

OpalHiiGetBrowserData();

- UnicodeStrToAsciiStrS (gHiiConfiguration.Psid, (CHAR8*)Psid.Psid, PSID_CHARACTER_LENGTH);
+ ZeroMem (TmpBuf, sizeof (TmpBuf));
+ UnicodeStrToAsciiStrS (gHiiConfiguration.Psid, (CHAR8*)TmpBuf, PSID_CHARACTER_STRING_END_LENGTH);
+ CopyMem (Psid.Psid, TmpBuf, PSID_CHARACTER_LENGTH);

OpalDisk = HiiGetOpalDiskCB (gHiiConfiguration.SelectedDiskIndex);
if (OpalDisk != NULL) {
diff --git a/SecurityPkg/Tcg/Opal/OpalPasswordDxe/OpalHiiFormValues.h b/SecurityPkg/Tcg/Opal/OpalPasswordDxe/OpalHiiFormValues.h
index 138bcb8..88cf9f5 100644
--- a/SecurityPkg/Tcg/Opal/OpalPasswordDxe/OpalHiiFormValues.h
+++ b/SecurityPkg/Tcg/Opal/OpalPasswordDxe/OpalHiiFormValues.h
@@ -21,6 +21,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.

// PSID Length
#define PSID_CHARACTER_LENGTH 0x20
+#define PSID_CHARACTER_STRING_END_LENGTH 0x21

// ID's for various forms that will be used by HII
#define FORMID_VALUE_MAIN_MENU 0x01
@@ -38,7 +39,7 @@ typedef struct {
UINT8 KeepUserData;
UINT16 AvailableFields;
UINT16 Password[MAX_PASSWORD_CHARACTER_LENGTH];
- UINT16 Psid[PSID_CHARACTER_LENGTH];
+ UINT16 Psid[PSID_CHARACTER_STRING_END_LENGTH];
UINT8 EnableBlockSid;
} OPAL_HII_CONFIGURATION;
#pragma pack()
--
2.6.4.windows.1


[Patch] BaseTools: Allow string token identifier to use lower case letters

Yonghong Zhu <yonghong.zhu@...>
 

This patch is to align the code behavior with UNI spec that string token
identifier can use upper case and lower case letters.

Cc: Liming Gao <liming.gao@intel.com>
Cc: Felix <Felixp@ami.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
---
BaseTools/Source/Python/AutoGen/UniClassObject.py | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/UniClassObject.py b/BaseTools/Source/Python/AutoGen/UniClassObject.py
index 183b2b2..856d19c 100644
--- a/BaseTools/Source/Python/AutoGen/UniClassObject.py
+++ b/BaseTools/Source/Python/AutoGen/UniClassObject.py
@@ -346,15 +346,15 @@ class UniFileClassObject(object):
def GetStringObject(self, Item):
Language = ''
Value = ''

Name = Item.split()[1]
- # Check the string name is the upper character
+ # Check the string name
if Name != '':
- MatchString = re.match('[A-Z0-9_]+', Name, re.UNICODE)
+ MatchString = re.match('^[a-zA-Z][a-zA-Z0-9_]*$', Name, re.UNICODE)
if MatchString == None or MatchString.end(0) != len(Name):
- EdkLogger.error('Unicode File Parser', FORMAT_INVALID, 'The string token name %s defined in UNI file %s contains the invalid lower case character.' % (Name, self.File))
+ EdkLogger.error('Unicode File Parser', FORMAT_INVALID, 'The string token name %s defined in UNI file %s contains the invalid character.' % (Name, self.File))
LanguageList = Item.split(u'#language ')
for IndexI in range(len(LanguageList)):
if IndexI == 0:
continue
else:
@@ -516,15 +516,15 @@ class UniFileClassObject(object):
else:
IndexI = IndexJ
break
# Value = Value.replace(u'\r\n', u'')
Language = GetLanguageCode(Language, self.IsCompatibleMode, self.File)
- # Check the string name is the upper character
+ # Check the string name
if not self.IsCompatibleMode and Name != '':
- MatchString = re.match('[A-Z0-9_]+', Name, re.UNICODE)
+ MatchString = re.match('^[a-zA-Z][a-zA-Z0-9_]*$', Name, re.UNICODE)
if MatchString == None or MatchString.end(0) != len(Name):
- EdkLogger.error('Unicode File Parser', FORMAT_INVALID, 'The string token name %s defined in UNI file %s contains the invalid lower case character.' % (Name, self.File))
+ EdkLogger.error('Unicode File Parser', FORMAT_INVALID, 'The string token name %s defined in UNI file %s contains the invalid character.' % (Name, self.File))
self.AddStringToList(Name, Language, Value)
continue

#
# Get string def information format 2 as below
--
2.6.1.windows.1


Re: [PATCH v5 0/8] BaseTools: add support for GCC5 in LTO mode

Ard Biesheuvel
 

On 2 August 2016 at 12:57, Laszlo Ersek <lersek@redhat.com> wrote:
On 08/02/16 11:03, Ard Biesheuvel wrote:
On 1 August 2016 at 10:01, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
This v5 to introduce GCC5 is now a 8 piece series, including some
preparatory cleanup patches that allow all GCC4x and CLANG35 toolchains
to switch to using 'gcc' as the linker. This allows us to get rid of
the wrapper script to marshall ld arguments in order to make them
understandable by gcc, which is fragile and likely to cause problems in
the future.

Since there appears to be a natural split between the 'legacy' GCC
toolchains UNIXGCC, ELFGCC, and CYGGCC[xASL], both in term of supported
architectures [IA32, X64, IPF] vs [IA32, X64, ARM, AARCH64], and in
terms of maintenance, these toolchains are not moved to using 'gcc' as
the linker, and instead, a new BUILDRULEFAMILY is introduced called GCCLD
that will retain the old behavior.

The result is that GCC5 can align much more closely with its predecessors,
making the expected maintenance burden of supporting GCC back to v4.4
much lower.

Changes since v4:
- added patch to use 'protected' visibility only for the libraries that
define the module entry points (_ModuleEntryPoint), to prevent them from
being optimized away by the LTO routines
- added Jordan's ack/RBs
- add some extra comments to tools_def.template (#8)
Thanks all. Committed as

1c63516075b3 BaseTools CLANG35: drop problematic use-movt and save-temps options
ff54bcdf2e4e ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: ignore .hash
and .note sections
befb3ba51502 BaseTools UNIXGCC ELFGCC CYGGCC: clone GCC build rule
family into GCCLD
a1b8baccc30b BaseTools GCC: use 'gcc' as the linker command for GCC44 and later
e1458aaded8e ArmPkg: add prebuilt glue binaries for GCC5 LTO support
7fd5d619806d BaseTools GCC: drop GNU notes section from EFI image
4a8466d4baba BaseTools GCC: introduce GCC5 toolchain to support GCC
v5.x in LTO mode

with Leif and Liming's R-b. I dropped patch #7, and instead made the
visibility pragma conditional on whether LTO is disabled.
Re gcc-5, do we need a patch for "OvmfPkg/build.sh" now? See also
<https://tianocore.acgmultimedia.com/show_bug.cgi?id=62>.
Yes, I suppose so.


Re: [PATCH v5 0/8] BaseTools: add support for GCC5 in LTO mode

Laszlo Ersek
 

On 08/02/16 11:03, Ard Biesheuvel wrote:
On 1 August 2016 at 10:01, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
This v5 to introduce GCC5 is now a 8 piece series, including some
preparatory cleanup patches that allow all GCC4x and CLANG35 toolchains
to switch to using 'gcc' as the linker. This allows us to get rid of
the wrapper script to marshall ld arguments in order to make them
understandable by gcc, which is fragile and likely to cause problems in
the future.

Since there appears to be a natural split between the 'legacy' GCC
toolchains UNIXGCC, ELFGCC, and CYGGCC[xASL], both in term of supported
architectures [IA32, X64, IPF] vs [IA32, X64, ARM, AARCH64], and in
terms of maintenance, these toolchains are not moved to using 'gcc' as
the linker, and instead, a new BUILDRULEFAMILY is introduced called GCCLD
that will retain the old behavior.

The result is that GCC5 can align much more closely with its predecessors,
making the expected maintenance burden of supporting GCC back to v4.4
much lower.

Changes since v4:
- added patch to use 'protected' visibility only for the libraries that
define the module entry points (_ModuleEntryPoint), to prevent them from
being optimized away by the LTO routines
- added Jordan's ack/RBs
- add some extra comments to tools_def.template (#8)
Thanks all. Committed as

1c63516075b3 BaseTools CLANG35: drop problematic use-movt and save-temps options
ff54bcdf2e4e ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: ignore .hash
and .note sections
befb3ba51502 BaseTools UNIXGCC ELFGCC CYGGCC: clone GCC build rule
family into GCCLD
a1b8baccc30b BaseTools GCC: use 'gcc' as the linker command for GCC44 and later
e1458aaded8e ArmPkg: add prebuilt glue binaries for GCC5 LTO support
7fd5d619806d BaseTools GCC: drop GNU notes section from EFI image
4a8466d4baba BaseTools GCC: introduce GCC5 toolchain to support GCC
v5.x in LTO mode

with Leif and Liming's R-b. I dropped patch #7, and instead made the
visibility pragma conditional on whether LTO is disabled.
Re gcc-5, do we need a patch for "OvmfPkg/build.sh" now? See also
<https://tianocore.acgmultimedia.com/show_bug.cgi?id=62>.

Thanks
Laszlo


Re: [PATCH] ShellBinPkg Arm/AArch64 Shell binary update

Ard Biesheuvel
 

On 2 August 2016 at 11:38, Leif Lindholm <leif.lindholm@linaro.org> wrote:
On Tue, Aug 02, 2016 at 11:21:48AM +0200, Ard Biesheuvel wrote:
The binaries of ShellBinPkg are generated with ShellPkg from b89919ee8f8c
("BaseTools AARCH64: override XIP module linker alignment to 32 bytes")

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
For the AArch64 variants:
Tested-by: Leif Lindholm <leif.lindholm@linaro.org>

And in general:
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Thanks

Pushed as 8134f7d9d265


[PATCH] ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: deal with relaxed XIP alignment

Ard Biesheuvel
 

Commit b89919ee8f8c ("BaseTools AARCH64: override XIP module linker
alignment to 32 bytes") updated the various AARCH64 toolchain definitions
to allow SEC, PEI_CORE and PEIM modules to be built with minimal alignment
requirements even when using the AArch64 small code model which normally
requires 4 KB section alignment.

This involves conversion of ADRP instructions into ADR instructions, which
can only be done reliably if the ELF and the PE/COFF sections appear at
the same offset modulo 4 KB.

The ArmVirtPrePiUniCoreRelocatable linker script did not yet take this
into account, so update it by starting the .text section at the next
appropriately aligned offset PECOFF_HEADER_SIZE bytes into the image.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---

This fixes the ArmVirtQemuKernel and ArmVirtXen platforms, which are currently
broken when using DEBUG_GCC49, DEBUG_GCC5 or *_CLANG35 (all of which received
the linker alignment treatment mentioned above)

Symptoms: many occurrences of
...
GenFw: ERROR 3000: Invalid
WriteSections64(): <../ArmVirtPrePiUniCoreRelocatable.dll> AARCH64 small
code model requires identical ELF and PE/COFF section offsets modulo 4 KB.
...

and a failed build.

ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds b/ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds
index 44df7840adfd..492a8fff380f 100644
--- a/ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds
+++ b/ArmVirtPkg/PrePi/Scripts/PrePi-PIE.lds
@@ -14,9 +14,10 @@

SECTIONS
{
- .text 0x0 : ALIGN(CONSTANT(COMMONPAGESIZE)) {
- PROVIDE(__reloc_base = .);
+ PROVIDE(__reloc_base = .);

+ . = PECOFF_HEADER_SIZE;
+ .text : ALIGN(CONSTANT(COMMONPAGESIZE)) {
*(.text .text*)
*(.got .got*)
*(.rodata .rodata*)
--
2.7.4


Re: [PATCH] ShellBinPkg Arm/AArch64 Shell binary update

Leif Lindholm <leif.lindholm@...>
 

On Tue, Aug 02, 2016 at 11:21:48AM +0200, Ard Biesheuvel wrote:
The binaries of ShellBinPkg are generated with ShellPkg from b89919ee8f8c
("BaseTools AARCH64: override XIP module linker alignment to 32 bytes")

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
For the AArch64 variants:
Tested-by: Leif Lindholm <leif.lindholm@linaro.org>

And in general:
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>

---

The binaries can be found here:
https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/arm-shell-update

ShellBinPkg/MinUefiShell/AArch64/Shell.efi | Bin 392416 -> 341280 bytes
ShellBinPkg/MinUefiShell/Arm/Shell.efi | Bin 338592 -> 297888 bytes
ShellBinPkg/UefiShell/AArch64/Shell.efi | Bin 893696 -> 827456 bytes
ShellBinPkg/UefiShell/Arm/Shell.efi | Bin 786592 -> 731680 bytes
4 files changed, 0 insertions(+), 0 deletions(-)

diff --git a/ShellBinPkg/MinUefiShell/AArch64/Shell.efi b/ShellBinPkg/MinUefiShell/AArch64/Shell.efi
index 53724a609171..162904634635 100755
Binary files a/ShellBinPkg/MinUefiShell/AArch64/Shell.efi and b/ShellBinPkg/MinUefiShell/AArch64/Shell.efi differ
diff --git a/ShellBinPkg/MinUefiShell/Arm/Shell.efi b/ShellBinPkg/MinUefiShell/Arm/Shell.efi
index 251e0ca38227..c84b17bdba80 100755
Binary files a/ShellBinPkg/MinUefiShell/Arm/Shell.efi and b/ShellBinPkg/MinUefiShell/Arm/Shell.efi differ
diff --git a/ShellBinPkg/UefiShell/AArch64/Shell.efi b/ShellBinPkg/UefiShell/AArch64/Shell.efi
index fdfd51803f93..6f2160bd1f46 100755
Binary files a/ShellBinPkg/UefiShell/AArch64/Shell.efi and b/ShellBinPkg/UefiShell/AArch64/Shell.efi differ
diff --git a/ShellBinPkg/UefiShell/Arm/Shell.efi b/ShellBinPkg/UefiShell/Arm/Shell.efi
index f7a8cca681d7..f8d46d496c05 100755
Binary files a/ShellBinPkg/UefiShell/Arm/Shell.efi and b/ShellBinPkg/UefiShell/Arm/Shell.efi differ
--
2.7.4