Date   

[PATCH 03/17] IntelFrameworkPkg DSC: Add build option to disable deprecated APIs

Wu, Hao A
 

Add the following definition in the [BuildOptions] section in package DSC
files to disable APIs that are deprecated:

[BuildOptions]
*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES

Cc: Jeff Fan <jeff.fan@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
---
IntelFrameworkPkg/IntelFrameworkPkg.dsc | 3 +++
1 file changed, 3 insertions(+)

diff --git a/IntelFrameworkPkg/IntelFrameworkPkg.dsc b/IntelFrameworkPkg/IntelFrameworkPkg.dsc
index afda3e7..2985d38 100644
--- a/IntelFrameworkPkg/IntelFrameworkPkg.dsc
+++ b/IntelFrameworkPkg/IntelFrameworkPkg.dsc
@@ -70,3 +70,6 @@
IntelFrameworkPkg/Library/PeiSmbusLibSmbusPpi/PeiSmbusLibSmbusPpi.inf
IntelFrameworkPkg/Library/PeiHobLibFramework/PeiHobLibFramework.inf

+[BuildOptions]
+ *_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
+
--
1.9.5.msysgit.0


[PATCH 02/17] IntelFrameworkModulePkg DSC: Add build option to disable deprecated APIs

Wu, Hao A
 

Add the following definition in the [BuildOptions] section in package DSC
files to disable APIs that are deprecated:

[BuildOptions]
*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES

Cc: Jeff Fan <jeff.fan@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
---
IntelFrameworkModulePkg/IntelFrameworkModulePkg.dsc | 3 +++
1 file changed, 3 insertions(+)

diff --git a/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dsc b/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dsc
index b5b0af7..a9a01aa 100644
--- a/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dsc
+++ b/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dsc
@@ -196,3 +196,6 @@
<LibraryClasses>
IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
}
+
+[BuildOptions]
+ *_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
--
1.9.5.msysgit.0


[PATCH 01/17] FatPkg DSC: Add build option to disable deprecated APIs

Wu, Hao A
 

Add the following definition in the [BuildOptions] section in package DSC
files to disable APIs that are deprecated:

[BuildOptions]
*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES

Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
---
FatPkg/FatPkg.dsc | 1 +
1 file changed, 1 insertion(+)

diff --git a/FatPkg/FatPkg.dsc b/FatPkg/FatPkg.dsc
index 9250ae0..d654120 100644
--- a/FatPkg/FatPkg.dsc
+++ b/FatPkg/FatPkg.dsc
@@ -31,6 +31,7 @@
INTEL:RELEASE_*_*_CC_FLAGS = /D MDEPKG_NDEBUG
MSFT:RELEASE_*_*_CC_FLAGS = /D MDEPKG_NDEBUG
RVCT:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
+ *_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES

[LibraryClasses]
#
--
1.9.5.msysgit.0


[PATCH 00/17] Add build option to disable deprecated APIs

Wu, Hao A
 

This patch series will add the following definition in the [BuildOptions]
section in package DSC files to disable APIs that are deprecated:

[BuildOptions]
*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES


Hao Wu (17):
FatPkg DSC: Add build option to disable deprecated APIs
IntelFrameworkModulePkg DSC: Add build option to disable deprecated
APIs
IntelFrameworkPkg DSC: Add build option to disable deprecated APIs
IntelFsp2Pkg DSC: Add build option to disable deprecated APIs
IntelFsp2WrapperPkg DSC: Add build option to disable deprecated APIs
IntelFspPkg DSC: Add build option to disable deprecated APIs
IntelFspWrapperPkg DSC: Add build option to disable deprecated APIs
MdeModulePkg DSC: Add build option to disable deprecated APIs
MdePkg DSC: Add build option to disable deprecated APIs
NetworkPkg DSC: Add build option to disable deprecated APIs
PcAtChipsetPkg DSC: Add build option to disable deprecated APIs
PerformancePkg DSC: Add build option to disable deprecated APIs
SecurityPkg DSC: Add build option to disable deprecated APIs
ShellPkg DSC: Add build option to disable deprecated APIs
SourceLevelDebugPkg DSC: Add build option to disable deprecated APIs
UefiCpuPkg DSC: Add build option to disable deprecated APIs
CryptoPkg DSC: Add build option to disable deprecated APIs

CryptoPkg/CryptoPkg.dsc | 3 +++
FatPkg/FatPkg.dsc | 1 +
IntelFrameworkModulePkg/IntelFrameworkModulePkg.dsc | 3 +++
IntelFrameworkPkg/IntelFrameworkPkg.dsc | 3 +++
IntelFsp2Pkg/IntelFsp2Pkg.dsc | 3 +++
IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dsc | 3 +++
IntelFspPkg/IntelFspPkg.dsc | 3 +++
IntelFspWrapperPkg/IntelFspWrapperPkg.dsc | 3 +++
MdeModulePkg/MdeModulePkg.dsc | 3 +++
MdePkg/MdePkg.dsc | 3 +++
NetworkPkg/NetworkPkg.dsc | 3 +++
PcAtChipsetPkg/PcAtChipsetPkg.dsc | 3 +++
PerformancePkg/PerformancePkg.dsc | 3 +++
SecurityPkg/SecurityPkg.dsc | 1 +
ShellPkg/ShellPkg.dsc | 2 ++
SourceLevelDebugPkg/SourceLevelDebugPkg.dsc | 3 +++
UefiCpuPkg/UefiCpuPkg.dsc | 3 +++
17 files changed, 46 insertions(+)

--
1.9.5.msysgit.0


Re: Managing GCC Assembly Code Size (AArch64)

Cohen, Eugene <eugene@...>
 

Ard, as usual you rock...

FYI there is a null token \() for GAS which you can use to concatenate
a string with a macro argument, e.g.,

.macro func, x
.globl \x
.type \x, %function
.section .text.\x
\x\():
.endm
Using the GAS .macro syntax this all collapses nicely. I tested it with one assembly function and all the right stuff happens.

So the request becomes: can we modify all of the assembly (at least Aarch64 please) to use this? How would you like to phase this in?

I think this would be an improvement, so go for it. The only thing to
be wary of is routines that fall through into the subsequent one.
Those need to remain in the same section.
Yes, I've accidentally modified these with disastrous results. I now know to stay away from them (ExceptionSupport.S in particular). :)

Thanks,

Eugene

-----Original Message-----
From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
Sent: Thursday, August 04, 2016 1:47 PM
To: Cohen, Eugene <eugene@hp.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>; edk2-devel@lists.01.org
Subject: Re: Managing GCC Assembly Code Size (AArch64)

On 4 August 2016 at 21:18, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
On 4 August 2016 at 20:08, Cohen, Eugene <eugene@hp.com>
wrote:
Ard and Leif,

I've been too backlogged to provide a real patchset at this point but
wanted to get your approval on this proposal...


As you know we have some code size sensitive uncompressed XIP
stuff going on. For C code we get dead code stripping thanks to the "-
ffunction-sections" switch which places each function in its own
section so the linker can strip unreferenced sections.

For assembly there is not a solution that's as easy. For RVCT we
handled this with an assembler macro that combined the procedure
label definition, export of global symbols and placement of the
procedure in its own section. For GCC I haven't found a way to fully do
this because we rely on the C preprocessor for assembly which means
you cannot expand to multi-line macros. (The label and assembler
directives require their own lines but the preprocessor collapses stuff
onto one line because in the C language newlines don't matter.)

So the solution I've settled on is to do this:

in MdePkg\Include\AArch64\ProcessorBind.h define:

/// Macro to place a function in its own section for dead code
elimination
/// This must be placed directly before the corresponding code
since the
/// .section directive applies to the code that follows it.
#define GCC_ASM_EXPORT_SECTION(func__) \
.global _CONCATENATE (__USER_LABEL_PREFIX__, func__)
;\
.section .text._CONCATENATE (__USER_LABEL_PREFIX__,
func__) ;\
.type ASM_PFX(func__), %function; \

This has the effect of placing the function in a section called
.text.<func__> so the linker can do its dead code stripping stuff. It also
absorbs the making the symbol globally visible so the corresponding
GCC_ASM_EXPORT statement can be removed.

then for every single assembly procedure change from this:

[top of file]
GCC_ASM_EXPORT (ArmInvalidateDataCacheEntryByMVA)

[lower down]
ASM_PFX(ArmInvalidateDataCacheEntryByMVA):
dc ivac, x0 // Invalidate single data cache line
ret

to this:

GCC_ASM_EXPORT_SECTION(ArmInvalidateDataCacheEntryByMVA)
ASM_PFX(ArmInvalidateDataCacheEntryByMVA):
dc ivac, x0 // Invalidate single data cache line
ret

Because the assembly label must appear in column 1 I couldn't find
a way to use the C preprocessor to absorb it so hence the two lines. If
you can find a way to improve on this it would be great.
What about GAS macros (.macro / .endm). I prefer those over cpp
macros
in assembler anyway.
FYI there is a null token \() for GAS which you can use to concatenate
a string with a macro argument, e.g.,

.macro func, x
.globl \x
.type \x, %function
.section .text.\x
\x\():
.endm


I'm not sure what impacts this might have to other toolchains - can
this be translated to CLANG and ARM Compiler?
The asm dialect is 99% aligned between CLANG and GNU as, so this
shouldn't be a problem

I'd like to get your OK on this conceptually and then I could
upstream some patches that modify the AArch64 *.S files to use this
approach. Unfortunately it won't be complete because I only updated
the libraries that we use. My hope is that long term all assembly (or at
least assembly in libraries) adopt this approach so we are positioned
for maximum dead code stripping.
I think this would be an improvement, so go for it. The only thing to
be wary of is routines that fall through into the subsequent one.
Those need to remain in the same section.


Re: Managing GCC Assembly Code Size (AArch64)

Ard Biesheuvel
 

On 4 August 2016 at 21:18, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
On 4 August 2016 at 20:08, Cohen, Eugene <eugene@hp.com> wrote:
Ard and Leif,

I've been too backlogged to provide a real patchset at this point but wanted to get your approval on this proposal...


As you know we have some code size sensitive uncompressed XIP stuff going on. For C code we get dead code stripping thanks to the "-ffunction-sections" switch which places each function in its own section so the linker can strip unreferenced sections.

For assembly there is not a solution that's as easy. For RVCT we handled this with an assembler macro that combined the procedure label definition, export of global symbols and placement of the procedure in its own section. For GCC I haven't found a way to fully do this because we rely on the C preprocessor for assembly which means you cannot expand to multi-line macros. (The label and assembler directives require their own lines but the preprocessor collapses stuff onto one line because in the C language newlines don't matter.)

So the solution I've settled on is to do this:

in MdePkg\Include\AArch64\ProcessorBind.h define:

/// Macro to place a function in its own section for dead code elimination
/// This must be placed directly before the corresponding code since the
/// .section directive applies to the code that follows it.
#define GCC_ASM_EXPORT_SECTION(func__) \
.global _CONCATENATE (__USER_LABEL_PREFIX__, func__) ;\
.section .text._CONCATENATE (__USER_LABEL_PREFIX__, func__) ;\
.type ASM_PFX(func__), %function; \

This has the effect of placing the function in a section called .text.<func__> so the linker can do its dead code stripping stuff. It also absorbs the making the symbol globally visible so the corresponding GCC_ASM_EXPORT statement can be removed.

then for every single assembly procedure change from this:

[top of file]
GCC_ASM_EXPORT (ArmInvalidateDataCacheEntryByMVA)

[lower down]
ASM_PFX(ArmInvalidateDataCacheEntryByMVA):
dc ivac, x0 // Invalidate single data cache line
ret

to this:

GCC_ASM_EXPORT_SECTION(ArmInvalidateDataCacheEntryByMVA)
ASM_PFX(ArmInvalidateDataCacheEntryByMVA):
dc ivac, x0 // Invalidate single data cache line
ret

Because the assembly label must appear in column 1 I couldn't find a way to use the C preprocessor to absorb it so hence the two lines. If you can find a way to improve on this it would be great.
What about GAS macros (.macro / .endm). I prefer those over cpp macros
in assembler anyway.
FYI there is a null token \() for GAS which you can use to concatenate
a string with a macro argument, e.g.,

.macro func, x
.globl \x
.type \x, %function
.section .text.\x
\x\():
.endm


I'm not sure what impacts this might have to other toolchains - can this be translated to CLANG and ARM Compiler?
The asm dialect is 99% aligned between CLANG and GNU as, so this
shouldn't be a problem

I'd like to get your OK on this conceptually and then I could upstream some patches that modify the AArch64 *.S files to use this approach. Unfortunately it won't be complete because I only updated the libraries that we use. My hope is that long term all assembly (or at least assembly in libraries) adopt this approach so we are positioned for maximum dead code stripping.
I think this would be an improvement, so go for it. The only thing to
be wary of is routines that fall through into the subsequent one.
Those need to remain in the same section.


Re: Managing GCC Assembly Code Size (AArch64)

Ard Biesheuvel
 

On 4 August 2016 at 20:08, Cohen, Eugene <eugene@hp.com> wrote:
Ard and Leif,

I've been too backlogged to provide a real patchset at this point but wanted to get your approval on this proposal...


As you know we have some code size sensitive uncompressed XIP stuff going on. For C code we get dead code stripping thanks to the "-ffunction-sections" switch which places each function in its own section so the linker can strip unreferenced sections.

For assembly there is not a solution that's as easy. For RVCT we handled this with an assembler macro that combined the procedure label definition, export of global symbols and placement of the procedure in its own section. For GCC I haven't found a way to fully do this because we rely on the C preprocessor for assembly which means you cannot expand to multi-line macros. (The label and assembler directives require their own lines but the preprocessor collapses stuff onto one line because in the C language newlines don't matter.)

So the solution I've settled on is to do this:

in MdePkg\Include\AArch64\ProcessorBind.h define:

/// Macro to place a function in its own section for dead code elimination
/// This must be placed directly before the corresponding code since the
/// .section directive applies to the code that follows it.
#define GCC_ASM_EXPORT_SECTION(func__) \
.global _CONCATENATE (__USER_LABEL_PREFIX__, func__) ;\
.section .text._CONCATENATE (__USER_LABEL_PREFIX__, func__) ;\
.type ASM_PFX(func__), %function; \

This has the effect of placing the function in a section called .text.<func__> so the linker can do its dead code stripping stuff. It also absorbs the making the symbol globally visible so the corresponding GCC_ASM_EXPORT statement can be removed.

then for every single assembly procedure change from this:

[top of file]
GCC_ASM_EXPORT (ArmInvalidateDataCacheEntryByMVA)

[lower down]
ASM_PFX(ArmInvalidateDataCacheEntryByMVA):
dc ivac, x0 // Invalidate single data cache line
ret

to this:

GCC_ASM_EXPORT_SECTION(ArmInvalidateDataCacheEntryByMVA)
ASM_PFX(ArmInvalidateDataCacheEntryByMVA):
dc ivac, x0 // Invalidate single data cache line
ret

Because the assembly label must appear in column 1 I couldn't find a way to use the C preprocessor to absorb it so hence the two lines. If you can find a way to improve on this it would be great.
What about GAS macros (.macro / .endm). I prefer those over cpp macros
in assembler anyway.

I'm not sure what impacts this might have to other toolchains - can this be translated to CLANG and ARM Compiler?
The asm dialect is 99% aligned between CLANG and GNU as, so this
shouldn't be a problem

I'd like to get your OK on this conceptually and then I could upstream some patches that modify the AArch64 *.S files to use this approach. Unfortunately it won't be complete because I only updated the libraries that we use. My hope is that long term all assembly (or at least assembly in libraries) adopt this approach so we are positioned for maximum dead code stripping.
I think this would be an improvement, so go for it. The only thing to
be wary of is routines that fall through into the subsequent one.
Those need to remain in the same section.


Re: [PATCH] BaseTools X64: fold PLT relocations into simple relative references

Ard Biesheuvel
 

On 4 aug. 2016, at 21:03, Nicolas Owens <mischief@offblast.org> wrote:

ard,

i think you need to have R_X86_64_PLT32 case in WriteRelocations64.
without that, i still hit the invalid relocation message.
Good point. I will send out a v2 tomorrow


On 08/04/2016 01:45 AM, Ard Biesheuvel wrote:
For X64/GCC, we use position independent code with hidden visibility
to inform the compiler that symbols references are never resolved at
runtime, which removes the need for PLTs and GOTs. However, in some
cases GCC has been reported to still emit PLT based relocations, which
we need to handle in the ELF to PE/COFF perform by GenFw.

Unlike GOT based relocations, which are non-trivial to handle since the
indirections in the code can not be fixed up easily (although relocation
types exist for X64 that annotate relocation targets as suitable for
relaxation), PLT relocations simply point to jump targets, and we can
relax such relocations by resolving them using the symbol directly rather
than via a PLT entry that does nothing more than tail call the function
we already know it is going to call (since all symbol references are
resolved in the same module).

So handle R_X86_64_PLT32 as a R_X86_64_PC32 relocation.

Suggested-by: Steven Shi <steven.shi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
BaseTools/Source/C/GenFw/Elf64Convert.c | 11 +++++++++++
1 file changed, 11 insertions(+)

diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c b/BaseTools/Source/C/GenFw/Elf64Convert.c
index 944c94b8f8b4..7cbff0df0996 100644
--- a/BaseTools/Source/C/GenFw/Elf64Convert.c
+++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
@@ -785,6 +785,17 @@ WriteSections64 (
*(INT32 *)Targ = (INT32)((INT64)(*(INT32 *)Targ) - SymShdr->sh_addr + mCoffSectionsOffset[Sym->st_shndx]);
VerboseMsg ("Relocation: 0x%08X", *(UINT32*)Targ);
break;
+
+ case R_X86_64_PLT32:
+ //
+ // Treat R_X86_64_PLT32 relocations as R_X86_64_PC32: this is
+ // possible since we know all code symbol references resolve to
+ // definitions in the same module (UEFI has no shared libraries),
+ // and so there is never a reason to jump via a PLT entry,
+ // allowing us to resolve the reference using the symbol directly.
+ //
+ VerboseMsg ("Treating R_X86_64_PLT32 as R_X86_64_PC32 ...");
+ /* fall through */
case R_X86_64_PC32:
//
// Relative relocation: Symbol - Ip + Addend


Re: [PATCH] BaseTools X64: fold PLT relocations into simple relative references

Nicolas Owens <mischief@...>
 

ard,

i think you need to have R_X86_64_PLT32 case in WriteRelocations64.
without that, i still hit the invalid relocation message.

On 08/04/2016 01:45 AM, Ard Biesheuvel wrote:
For X64/GCC, we use position independent code with hidden visibility
to inform the compiler that symbols references are never resolved at
runtime, which removes the need for PLTs and GOTs. However, in some
cases GCC has been reported to still emit PLT based relocations, which
we need to handle in the ELF to PE/COFF perform by GenFw.

Unlike GOT based relocations, which are non-trivial to handle since the
indirections in the code can not be fixed up easily (although relocation
types exist for X64 that annotate relocation targets as suitable for
relaxation), PLT relocations simply point to jump targets, and we can
relax such relocations by resolving them using the symbol directly rather
than via a PLT entry that does nothing more than tail call the function
we already know it is going to call (since all symbol references are
resolved in the same module).

So handle R_X86_64_PLT32 as a R_X86_64_PC32 relocation.

Suggested-by: Steven Shi <steven.shi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
BaseTools/Source/C/GenFw/Elf64Convert.c | 11 +++++++++++
1 file changed, 11 insertions(+)

diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c b/BaseTools/Source/C/GenFw/Elf64Convert.c
index 944c94b8f8b4..7cbff0df0996 100644
--- a/BaseTools/Source/C/GenFw/Elf64Convert.c
+++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
@@ -785,6 +785,17 @@ WriteSections64 (
*(INT32 *)Targ = (INT32)((INT64)(*(INT32 *)Targ) - SymShdr->sh_addr + mCoffSectionsOffset[Sym->st_shndx]);
VerboseMsg ("Relocation: 0x%08X", *(UINT32*)Targ);
break;
+
+ case R_X86_64_PLT32:
+ //
+ // Treat R_X86_64_PLT32 relocations as R_X86_64_PC32: this is
+ // possible since we know all code symbol references resolve to
+ // definitions in the same module (UEFI has no shared libraries),
+ // and so there is never a reason to jump via a PLT entry,
+ // allowing us to resolve the reference using the symbol directly.
+ //
+ VerboseMsg ("Treating R_X86_64_PLT32 as R_X86_64_PC32 ...");
+ /* fall through */
case R_X86_64_PC32:
//
// Relative relocation: Symbol - Ip + Addend


Managing GCC Assembly Code Size (AArch64)

Cohen, Eugene <eugene@...>
 

Ard and Leif,

I've been too backlogged to provide a real patchset at this point but wanted to get your approval on this proposal...


As you know we have some code size sensitive uncompressed XIP stuff going on. For C code we get dead code stripping thanks to the "-ffunction-sections" switch which places each function in its own section so the linker can strip unreferenced sections.

For assembly there is not a solution that's as easy. For RVCT we handled this with an assembler macro that combined the procedure label definition, export of global symbols and placement of the procedure in its own section. For GCC I haven't found a way to fully do this because we rely on the C preprocessor for assembly which means you cannot expand to multi-line macros. (The label and assembler directives require their own lines but the preprocessor collapses stuff onto one line because in the C language newlines don't matter.)

So the solution I've settled on is to do this:

in MdePkg\Include\AArch64\ProcessorBind.h define:

/// Macro to place a function in its own section for dead code elimination
/// This must be placed directly before the corresponding code since the
/// .section directive applies to the code that follows it.
#define GCC_ASM_EXPORT_SECTION(func__) \
.global _CONCATENATE (__USER_LABEL_PREFIX__, func__) ;\
.section .text._CONCATENATE (__USER_LABEL_PREFIX__, func__) ;\
.type ASM_PFX(func__), %function; \

This has the effect of placing the function in a section called .text.<func__> so the linker can do its dead code stripping stuff. It also absorbs the making the symbol globally visible so the corresponding GCC_ASM_EXPORT statement can be removed.

then for every single assembly procedure change from this:

[top of file]
GCC_ASM_EXPORT (ArmInvalidateDataCacheEntryByMVA)

[lower down]
ASM_PFX(ArmInvalidateDataCacheEntryByMVA):
dc ivac, x0 // Invalidate single data cache line
ret

to this:

GCC_ASM_EXPORT_SECTION(ArmInvalidateDataCacheEntryByMVA)
ASM_PFX(ArmInvalidateDataCacheEntryByMVA):
dc ivac, x0 // Invalidate single data cache line
ret

Because the assembly label must appear in column 1 I couldn't find a way to use the C preprocessor to absorb it so hence the two lines. If you can find a way to improve on this it would be great.

I'm not sure what impacts this might have to other toolchains - can this be translated to CLANG and ARM Compiler?

I'd like to get your OK on this conceptually and then I could upstream some patches that modify the AArch64 *.S files to use this approach. Unfortunately it won't be complete because I only updated the libraries that we use. My hope is that long term all assembly (or at least assembly in libraries) adopt this approach so we are positioned for maximum dead code stripping.

Thanks,

Eugene


Re: [PATCH 3/3] BaseTools GCC/ARM: add -fno-builtin to CC flags

Michael Zimmermann
 

not directly related but could we add nostdinc too? At least for my
platform that works perfectly and it prevents you from accidentally
including any libc/libgcc/whatever headers from your toolchain.(nostdlib is
already enabled)

Thanks
Michael

On Thu, Aug 4, 2016 at 4:42 PM, Ard Biesheuvel <ard.biesheuvel@linaro.org>
wrote:

Avoid build errors when including OpensslLib, which may throw
undefined reference errors for builtin functions if -fno-builtin
is not specified (and it is already set for IA32, X64 and AARCH64)
So set it for ARM as well.

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

diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.
template
index 88af82a683d9..4f1dd4be378e 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -4334,7 +4334,7 @@ DEFINE GCC_ALL_CC_FLAGS = -g -Os
-fshort-wchar -fno-strict-aliasing -
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
-DEFINE GCC_ARM_CC_FLAGS = DEF(GCC_ALL_CC_FLAGS)
-mlittle-endian -mabi=aapcs -fno-short-enums -funsigned-char
-ffunction-sections -fdata-sections -fomit-frame-pointer -Wno-address
-mthumb -mfloat-abi=soft
+DEFINE GCC_ARM_CC_FLAGS = DEF(GCC_ALL_CC_FLAGS)
-mlittle-endian -mabi=aapcs -fno-short-enums -funsigned-char
-ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin
-Wno-address -mthumb -mfloat-abi=soft
DEFINE GCC_AARCH64_CC_FLAGS = DEF(GCC_ALL_CC_FLAGS)
-mlittle-endian -fno-short-enums -fverbose-asm -funsigned-char
-ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin
-Wno-address -fno-asynchronous-unwind-tables
DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align
DEFINE GCC_DLINK_FLAGS_COMMON = -nostdlib --pie
--
2.7.4

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


[PATCH 3/3] BaseTools GCC/ARM: add -fno-builtin to CC flags

Ard Biesheuvel
 

Avoid build errors when including OpensslLib, which may throw
undefined reference errors for builtin functions if -fno-builtin
is not specified (and it is already set for IA32, X64 and AARCH64)
So set it for ARM as well.

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

diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template
index 88af82a683d9..4f1dd4be378e 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -4334,7 +4334,7 @@ DEFINE GCC_ALL_CC_FLAGS = -g -Os -fshort-wchar -fno-strict-aliasing -
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
-DEFINE GCC_ARM_CC_FLAGS = DEF(GCC_ALL_CC_FLAGS) -mlittle-endian -mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft
+DEFINE GCC_ARM_CC_FLAGS = DEF(GCC_ALL_CC_FLAGS) -mlittle-endian -mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address -mthumb -mfloat-abi=soft
DEFINE GCC_AARCH64_CC_FLAGS = DEF(GCC_ALL_CC_FLAGS) -mlittle-endian -fno-short-enums -fverbose-asm -funsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address -fno-asynchronous-unwind-tables
DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align
DEFINE GCC_DLINK_FLAGS_COMMON = -nostdlib --pie
--
2.7.4


[PATCH 2/3] ArmPkg/CompilerIntrinsicsLib: make the default memset() weak

Ard Biesheuvel
 

The ARM compiler intrinsics library defines __aeabi_memset() and
memset() in the same object, which means that both will be pulled
in if either is referenced.

The IntrinsicLib in CryptoPkg defines its own, preferred memset(),
which may clash with our memset(). So make our version weak.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
ArmPkg/Library/CompilerIntrinsicsLib/Arm/memset.S | 8 ++++++++
1 file changed, 8 insertions(+)

diff --git a/ArmPkg/Library/CompilerIntrinsicsLib/Arm/memset.S b/ArmPkg/Library/CompilerIntrinsicsLib/Arm/memset.S
index bb75d7a70b80..65f6289b410b 100644
--- a/ArmPkg/Library/CompilerIntrinsicsLib/Arm/memset.S
+++ b/ArmPkg/Library/CompilerIntrinsicsLib/Arm/memset.S
@@ -40,6 +40,14 @@ ASM_PFX(__aeabi_memset):
# IN UINT32 Character,
# IN UINT32 Size
# );
+ //
+ // This object may be pulled in to satisfy an undefined reference to
+ // __aeabi_memset above, but in some cases, memset() is already provided
+ // by another library (i.e., CryptoPkg/IntrinsicLib), in which case we
+ // prefer the other version. So allow this one to be overridden by
+ // giving it weak linkage.
+ //
+ .weak memset
ASM_PFX(memset):
subs ip, r2, #0
bxeq lr
--
2.7.4


[PATCH 1/3] ArmPkg/ArmSoftFloatLib: disable LTO build for GCC

Ard Biesheuvel
 

Building ArmSoftFloatLib with LTO results in errors like

.../bin/ld: softfloat.obj: plugin needed to handle lto object
.../bin/ld: __aeabi_dcmpge.obj: plugin needed to handle lto object
.../bin/ld: __aeabi_dcmplt.obj: plugin needed to handle lto object
.../bin/ld: internal error ../../ld/ldlang.c 6299

This library is only linked by OpensslLib at the moment, and only
marginally used at runtime, so just disable LTO for it.

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

diff --git a/ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf b/ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf
index f090b3f288ce..3c76381b25dc 100644
--- a/ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf
+++ b/ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf
@@ -48,7 +48,7 @@ [Packages]
MdePkg/MdePkg.dec

[BuildOptions]
- GCC:*_*_*_CC_FLAGS = -DSOFTFLOAT_FOR_GCC -Wno-enum-compare
+ GCC:*_*_*_CC_FLAGS = -DSOFTFLOAT_FOR_GCC -Wno-enum-compare -fno-lto
*_GCC46_*_CC_FLAGS = -fno-tree-vrp
*_GCC47_*_CC_FLAGS = -fno-tree-vrp
RVCT:*_*_*_CC_FLAGS = -DSOFTFLOAT_FOR_GCC
--
2.7.4


[PATCH 0/3] Build fixes for ARM/OpenSSL

Ard Biesheuvel
 

This series addresses some issues that cause the build to be broken
for ARM GCC5 at the moment when including OpensslLib in the build.

Ard Biesheuvel (3):
ArmPkg/ArmSoftFloatLib: disable LTO build for GCC
ArmPkg/CompilerIntrinsicsLib: make the default memset() weak
BaseTools GCC/ARM: add -fno-builtin to CC flags

ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf | 2 +-
ArmPkg/Library/CompilerIntrinsicsLib/Arm/memset.S | 8 ++++++++
BaseTools/Conf/tools_def.template | 2 +-
3 files changed, 10 insertions(+), 2 deletions(-)

--
2.7.4


Re: [PATCH] PcdBdsLinuxSupport default value

Leif Lindholm <leif.lindholm@...>
 

On Wed, Aug 03, 2016 at 06:10:48PM -0500, Daniil Egranov wrote:
The built-in Linux Loader is obsolete and not included in most builds.
The patch sets the PcdBdsLinuxSupport default value to FALSE and prevents
ArmBds from looking for built-in Linux Loader by default and ASSERTing
when it cannot be found. Platforms which still using built-in loader have
to set this PCD in their platform description file.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Daniil Egranov <daniil.egranov@arm.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Pushed (with a tweak to the subject line), thanks!

---
ArmPlatformPkg/ArmPlatformPkg.dec | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec b/ArmPlatformPkg/ArmPlatformPkg.dec
index 5864d98..d756fd2 100644
--- a/ArmPlatformPkg/ArmPlatformPkg.dec
+++ b/ArmPlatformPkg/ArmPlatformPkg.dec
@@ -55,7 +55,7 @@
gArmPlatformTokenSpaceGuid.PcdGopDisableOnExitBootServices|FALSE|BOOLEAN|0x0000003D

# Enable Legacy Linux support in the BDS
- gArmPlatformTokenSpaceGuid.PcdBdsLinuxSupport|TRUE|BOOLEAN|0x0000002E
+ gArmPlatformTokenSpaceGuid.PcdBdsLinuxSupport|FALSE|BOOLEAN|0x0000002E

[PcdsFixedAtBuild.common]
gArmPlatformTokenSpaceGuid.PcdCoreCount|1|UINT32|0x00000039
--
2.7.4


Re: [PATCH 3/3] SecurityPkg Tcg2: Remove internal implementation of IsZeroBuffer()

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

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





Thanks & Best regards
Chao Zhang

-----Original Message-----
From: Wu, Hao A
Sent: Thursday, August 04, 2016 9:24 AM
To: edk2-devel@lists.01.org
Cc: Wu, Hao A; Yao, Jiewen; Zhang, Chao B
Subject: [PATCH 3/3] SecurityPkg Tcg2: Remove internal implementation of IsZeroBuffer()

This commit removes the internal implementation of the function
IsZeroBuffer(). Instead, it will use the one from BaseMemoryLib.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
---
SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigImpl.c | 27 ---------------------------
SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c | 27 ---------------------------
SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c | 27 ---------------------------
3 files changed, 81 deletions(-)

diff --git a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigImpl.c b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigImpl.c
index db38bd4..5f4420c 100644
--- a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigImpl.c
+++ b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigImpl.c
@@ -617,33 +617,6 @@ FillBufferWithTCG2EventLogFormat (
}

/**
- Check if buffer is all zero.
-
- @param[in] Buffer Buffer to be checked.
- @param[in] BufferSize Size of buffer to be checked.
-
- @retval TRUE Buffer is all zero.
- @retval FALSE Buffer is not all zero.
-**/
-BOOLEAN
-IsZeroBuffer (
- IN VOID *Buffer,
- IN UINTN BufferSize
- )
-{
- UINT8 *BufferData;
- UINTN Index;
-
- BufferData = Buffer;
- for (Index = 0; Index < BufferSize; Index++) {
- if (BufferData[Index] != 0) {
- return FALSE;
- }
- }
- return TRUE;
-}
-
-/**
This function publish the TCG2 configuration Form for TPM device.

@param[in, out] PrivateData Points to TCG2 configuration private data.
diff --git a/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c b/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c
index 95219c0..319f245 100644
--- a/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c
+++ b/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c
@@ -202,33 +202,6 @@ InternalDumpHex (
}

/**
- Check if buffer is all zero.
-
- @param[in] Buffer Buffer to be checked.
- @param[in] BufferSize Size of buffer to be checked.
-
- @retval TRUE Buffer is all zero.
- @retval FALSE Buffer is not all zero.
-**/
-BOOLEAN
-IsZeroBuffer (
- IN VOID *Buffer,
- IN UINTN BufferSize
- )
-{
- UINT8 *BufferData;
- UINTN Index;
-
- BufferData = Buffer;
- for (Index = 0; Index < BufferSize; Index++) {
- if (BufferData[Index] != 0) {
- return FALSE;
- }
- }
- return TRUE;
-}
-
-/**
Get All processors EFI_CPU_LOCATION in system. LocationBuf is allocated inside the function
Caller is responsible to free LocationBuf.

diff --git a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c
index a830ba8..0d779f1 100644
--- a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c
+++ b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c
@@ -225,33 +225,6 @@ EndofPeiSignalNotifyCallBack (
}

/**
- Check if buffer is all zero.
-
- @param[in] Buffer Buffer to be checked.
- @param[in] BufferSize Size of buffer to be checked.
-
- @retval TRUE Buffer is all zero.
- @retval FALSE Buffer is not all zero.
-**/
-BOOLEAN
-IsZeroBuffer (
- IN VOID *Buffer,
- IN UINTN BufferSize
- )
-{
- UINT8 *BufferData;
- UINTN Index;
-
- BufferData = Buffer;
- for (Index = 0; Index < BufferSize; Index++) {
- if (BufferData[Index] != 0) {
- return FALSE;
- }
- }
- return TRUE;
-}
-
-/**
Get TPML_DIGEST_VALUES data size.

@param[in] DigestList TPML_DIGEST_VALUES data.
--
1.9.5.msysgit.0


Re: [PATCH] BaseTools X64: fold PLT relocations into simple relative references

Ard Biesheuvel
 

On 4 August 2016 at 10:58, Shi, Steven <steven.shi@intel.com> wrote:
OK, it is. But it is a bit not very clear.
Did you read the elaborate comment block explaining that (and why) it
is appropriate to treat R_X86_64_PLT32 as a R_X86_64_PC32 relocation?
This is not generally true, but it is true for UEFI since we don't
support shared libraries.

So I think it is incorrect to simply duplicate the code for
R_X86_64_PC32 without mentioning that, and suggesting that the PLT
relocation receive some kind of treatment that is different.

Thanks,
Ard.


Re: [PATCH] BaseTools X64: fold PLT relocations into simple relative references

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

OK, it is. But it is a bit not very clear.





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: Thursday, August 04, 2016 4:55 PM
To: Shi, Steven <steven.shi@intel.com>
Cc: 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; mischief@offblast.org
Subject: Re: [PATCH] BaseTools X64: fold PLT relocations into simple relative
references
On 4 August 2016 at 10:54, Shi, Steven <steven.shi@intel.com<mailto:steven.shi@intel.com>> wrote:
Hi Ard,
I don't see you add below code for case R_X86_64_PLT32. Is it right?
*(UINT32 *)Targ = (UINT32) (*(UINT32 *)Targ
+ (mCoffSectionsOffset[Sym->st_shndx] - SymShdr->sh_addr)
- (SecOffset - SecShdr->sh_addr));
Isn't it identical to the code for R_X86_64_PC32?


Re: [PATCH] BaseTools X64: fold PLT relocations into simple relative references

Ard Biesheuvel
 

On 4 August 2016 at 10:54, Shi, Steven <steven.shi@intel.com> wrote:
Hi Ard,
I don't see you add below code for case R_X86_64_PLT32. Is it right?

*(UINT32 *)Targ = (UINT32) (*(UINT32 *)Targ
+ (mCoffSectionsOffset[Sym->st_shndx] - SymShdr->sh_addr)
- (SecOffset - SecShdr->sh_addr));
Isn't it identical to the code for R_X86_64_PC32?