Date   

[PATCH 08/17] MdeModulePkg 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: Feng Tian <feng.tian@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
---
MdeModulePkg/MdeModulePkg.dsc | 3 +++
1 file changed, 3 insertions(+)

diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index ce29eb9..05120c7 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -460,3 +460,6 @@
[Components.X64]
MdeModulePkg/Universal/CapsulePei/CapsuleX64.inf

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


[PATCH 07/17] IntelFspWrapperPkg 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: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
---
IntelFspWrapperPkg/IntelFspWrapperPkg.dsc | 3 +++
1 file changed, 3 insertions(+)

diff --git a/IntelFspWrapperPkg/IntelFspWrapperPkg.dsc b/IntelFspWrapperPkg/IntelFspWrapperPkg.dsc
index 3714e30..c960388 100644
--- a/IntelFspWrapperPkg/IntelFspWrapperPkg.dsc
+++ b/IntelFspWrapperPkg/IntelFspWrapperPkg.dsc
@@ -83,3 +83,6 @@
gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x1f
gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80080046
gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x07
+
+[BuildOptions]
+ *_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
--
1.9.5.msysgit.0


[PATCH 06/17] IntelFspPkg 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: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
---
IntelFspPkg/IntelFspPkg.dsc | 3 +++
1 file changed, 3 insertions(+)

diff --git a/IntelFspPkg/IntelFspPkg.dsc b/IntelFspPkg/IntelFspPkg.dsc
index f3b5689..01b6e46 100644
--- a/IntelFspPkg/IntelFspPkg.dsc
+++ b/IntelFspPkg/IntelFspPkg.dsc
@@ -72,3 +72,6 @@
gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x1f
gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80080046
gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x07
+
+[BuildOptions]
+ *_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
--
1.9.5.msysgit.0


[PATCH 05/17] IntelFsp2WrapperPkg 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: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
---
IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dsc | 3 +++
1 file changed, 3 insertions(+)

diff --git a/IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dsc b/IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dsc
index 8292030..6496dad 100644
--- a/IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dsc
+++ b/IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dsc
@@ -92,3 +92,6 @@
gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x1f
gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80080046
gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x07
+
+[BuildOptions]
+ *_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
--
1.9.5.msysgit.0


[PATCH 04/17] IntelFsp2Pkg 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: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
---
IntelFsp2Pkg/IntelFsp2Pkg.dsc | 3 +++
1 file changed, 3 insertions(+)

diff --git a/IntelFsp2Pkg/IntelFsp2Pkg.dsc b/IntelFsp2Pkg/IntelFsp2Pkg.dsc
index 61eb6f1..1469d35 100644
--- a/IntelFsp2Pkg/IntelFsp2Pkg.dsc
+++ b/IntelFsp2Pkg/IntelFsp2Pkg.dsc
@@ -77,3 +77,6 @@
gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x1f
gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80080046
gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x07
+
+[BuildOptions]
+ *_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
--
1.9.5.msysgit.0


[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