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


Ard Biesheuvel
 

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)

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


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

Ard,
Where can I check out your v5 patch?


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: Monday, August 01, 2016 4:01 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@lists.01.org
Cc: leif.lindholm@linaro.org; lersek@redhat.com; Ard Biesheuvel
<ard.biesheuvel@linaro.org>
Subject: [PATCH v5 0/8] BaseTools: add support for GCC5 in LTO mode

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)

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


Ard Biesheuvel
 

On 1 August 2016 at 16:01, Shi, Steven <steven.shi@intel.com> wrote:
Ard,
Where can I check out your v5 patch?
https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/gcc5-lto-v5

or

git://git.linaro.org/people/ard.biesheuvel/uefi-next.git gcc5-lto-v5

Thanks,
Ard.


Ard Biesheuvel
 

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


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


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.


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


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.


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


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?


Michael Zimmermann
 

Sry for the late reply but I tried your latest gcc-lto branch to make sure
my answers are still correct.
I tested it with all configurations(StdLib:X64/ARM, Ovmf:X64,
ArmVirtPkg:ARM with both RELEASE and DEBUG).
In StdLib are many warnings actually. That's because
of -Wunused-const-variable and -Wmisleading-indentation.
Also I had to apply the commit to fix 'Unsupported ELF EM_X86_64 relocation
0x4.' for X64.

'-b RELEASE -a ARM -t GCC5 -p AppPkg/AppPkg.dsc' is the only configuration
I can't get to compile with gcc6(DEBUG works):
/tmp/ccYJi1bO.ltrans0.ltrans.o: In function `memmove':
<artificial>:(.text+0x3670): multiple definition of `memmove'
/media/Data/repositories/git/efidroid/testing/linuxtoolchain/edk2/Build/AppPkg/RELEASE_GCC5/ARM/ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib/OUTPUT/CompilerIntrinsicsLib.lib(memmove.obj):(.text+0x0):
first defined here
/tmp/ccYJi1bO.ltrans0.ltrans.o: In function `memset':
<artificial>:(.text+0x3674): multiple definition of `memset'
/media/Data/repositories/git/efidroid/testing/linuxtoolchain/edk2/Build/AppPkg/RELEASE_GCC5/ARM/ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib/OUTPUT/CompilerIntrinsicsLib.lib(memset.obj):(.text+0x10):
first defined here
/media/Data/repositories/git/efidroid/prebuilts/gcc/linux-x86/arm/gcc-linaro-6.1.1~linaro-gcc-6-branch@f3888e76-20160721-x86_64_arm-eabi/bin/../lib/gcc/arm-eabi/6.1.1/../../../../arm-eabi/bin/ld:
printf.obj: plugin needed to handle lto object
/media/Data/repositories/git/efidroid/prebuilts/gcc/linux-x86/arm/gcc-linaro-6.1.1~linaro-gcc-6-branch@f3888e76-20160721-x86_64_arm-eabi/bin/../lib/gcc/arm-eabi/6.1.1/../../../../arm-eabi/bin/ld:
puts.obj: plugin needed to handle lto object
/media/Data/repositories/git/efidroid/prebuilts/gcc/linux-x86/arm/gcc-linaro-6.1.1~linaro-gcc-6-branch@f3888e76-20160721-x86_64_arm-eabi/bin/../lib/gcc/arm-eabi/6.1.1/../../../../arm-eabi/bin/ld:
internal error
/media/Data/repositories/git/abe/_build/snapshots/binutils-gdb.git~linaro_binutils-2_26-branch/ld/ldlang.c
6299
collect2: error: ld returned 1 exit status
make: *** [GNUmakefile:417:
/media/Data/repositories/git/efidroid/testing/linuxtoolchain/edk2/Build/AppPkg/RELEASE_GCC5/ARM/AppPkg/Applications/Main/Main/DEBUG/Main.dll]
Error 1

Also, I only did compilation tests, I didn't try to run any of the produced
binaries.

this is the fixed branch:
https://github.com/M1cha/edk2/commits/edk2-master-gcc6
it's based on your gcc5-lto-v6 branch.

Thanks
Michael

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

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?


Michael Zimmermann
 

sry but I have to retest everything since I aciidentally checked out a
wrong revision.
will report back later.

On Tue, Aug 2, 2016 at 4:39 PM, Michael Zimmermann <sigmaepsilon92@gmail.com
wrote:
Sry for the late reply but I tried your latest gcc-lto branch to make sure
my answers are still correct.
I tested it with all configurations(StdLib:X64/ARM, Ovmf:X64,
ArmVirtPkg:ARM with both RELEASE and DEBUG).
In StdLib are many warnings actually. That's because
of -Wunused-const-variable and -Wmisleading-indentation.
Also I had to apply the commit to fix 'Unsupported ELF EM_X86_64
relocation 0x4.' for X64.

'-b RELEASE -a ARM -t GCC5 -p AppPkg/AppPkg.dsc' is the only configuration
I can't get to compile with gcc6(DEBUG works):
/tmp/ccYJi1bO.ltrans0.ltrans.o: In function `memmove':
<artificial>:(.text+0x3670): multiple definition of `memmove'
/media/Data/repositories/git/efidroid/testing/linuxtoolchain/edk2/Build/AppPkg/RELEASE_GCC5/ARM/ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib/OUTPUT/CompilerIntrinsicsLib.lib(memmove.obj):(.text+0x0):
first defined here
/tmp/ccYJi1bO.ltrans0.ltrans.o: In function `memset':
<artificial>:(.text+0x3674): multiple definition of `memset'
/media/Data/repositories/git/efidroid/testing/linuxtoolchain/edk2/Build/AppPkg/RELEASE_GCC5/ARM/ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib/OUTPUT/CompilerIntrinsicsLib.lib(memset.obj):(.text+0x10):
first defined here

/media/Data/repositories/git/efidroid/prebuilts/gcc/linux-x86/arm/gcc-linaro-6.1.1~linaro-gcc-6-branch@f3888e76-20160721-x86_64_arm-eabi/bin/../lib/gcc/arm-eabi/6.1.1/../../../../arm-eabi/bin/ld:
printf.obj: plugin needed to handle lto object

/media/Data/repositories/git/efidroid/prebuilts/gcc/linux-x86/arm/gcc-linaro-6.1.1~linaro-gcc-6-branch@f3888e76-20160721-x86_64_arm-eabi/bin/../lib/gcc/arm-eabi/6.1.1/../../../../arm-eabi/bin/ld:
puts.obj: plugin needed to handle lto object

/media/Data/repositories/git/efidroid/prebuilts/gcc/linux-x86/arm/gcc-linaro-6.1.1~linaro-gcc-6-branch@f3888e76-20160721-x86_64_arm-eabi/bin/../lib/gcc/arm-eabi/6.1.1/../../../../arm-eabi/bin/ld:
internal error
/media/Data/repositories/git/abe/_build/snapshots/binutils-gdb.git~linaro_binutils-2_26-branch/ld/ldlang.c
6299
collect2: error: ld returned 1 exit status
make: *** [GNUmakefile:417:
/media/Data/repositories/git/efidroid/testing/linuxtoolchain/edk2/Build/AppPkg/RELEASE_GCC5/ARM/AppPkg/Applications/Main/Main/DEBUG/Main.dll]
Error 1

Also, I only did compilation tests, I didn't try to run any of the
produced binaries.

this is the fixed branch:
https://github.com/M1cha/edk2/commits/edk2-master-gcc6
it's based on your gcc5-lto-v6 branch.

Thanks
Michael

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

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?


Ard Biesheuvel
 

On 2 August 2016 at 16:39, Michael Zimmermann <sigmaepsilon92@gmail.com> wrote:
Sry for the late reply but I tried your latest gcc-lto branch to make sure
my answers are still correct.
I tested it with all configurations(StdLib:X64/ARM, Ovmf:X64, ArmVirtPkg:ARM
with both RELEASE and DEBUG).
In StdLib are many warnings actually. That's because of
-Wunused-const-variable and -Wmisleading-indentation.
Also I had to apply the commit to fix 'Unsupported ELF EM_X86_64 relocation
0x4.' for X64.
Only 0x4 or 0x9 or others as well? This is relevent since 0x4 is a PLT
relocation which can be fixed up easily. The GOT based ones are
trickier since they involve a GOT entry with an absolute symbol
address that needs to be fixed up by the PE/COFF loader

'-b RELEASE -a ARM -t GCC5 -p AppPkg/AppPkg.dsc' is the only configuration I
can't get to compile with gcc6(DEBUG works):
/tmp/ccYJi1bO.ltrans0.ltrans.o: In function `memmove':
<artificial>:(.text+0x3670): multiple definition of `memmove'
/media/Data/repositories/git/efidroid/testing/linuxtoolchain/edk2/Build/AppPkg/RELEASE_GCC5/ARM/ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib/OUTPUT/CompilerIntrinsicsLib.lib(memmove.obj):(.text+0x0):
first defined here
/tmp/ccYJi1bO.ltrans0.ltrans.o: In function `memset':
<artificial>:(.text+0x3674): multiple definition of `memset'
/media/Data/repositories/git/efidroid/testing/linuxtoolchain/edk2/Build/AppPkg/RELEASE_GCC5/ARM/ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib/OUTPUT/CompilerIntrinsicsLib.lib(memset.obj):(.text+0x10):
first defined here
Interesting. I wonder where the first memmove resp. memset are coming
from. Are you linking with libgcc are sth like that?

/media/Data/repositories/git/efidroid/prebuilts/gcc/linux-x86/arm/gcc-linaro-6.1.1~linaro-gcc-6-branch@f3888e76-20160721-x86_64_arm-eabi/bin/../lib/gcc/arm-eabi/6.1.1/../../../../arm-eabi/bin/ld:
printf.obj: plugin needed to handle lto object
/media/Data/repositories/git/efidroid/prebuilts/gcc/linux-x86/arm/gcc-linaro-6.1.1~linaro-gcc-6-branch@f3888e76-20160721-x86_64_arm-eabi/bin/../lib/gcc/arm-eabi/6.1.1/../../../../arm-eabi/bin/ld:
puts.obj: plugin needed to handle lto object
/media/Data/repositories/git/efidroid/prebuilts/gcc/linux-x86/arm/gcc-linaro-6.1.1~linaro-gcc-6-branch@f3888e76-20160721-x86_64_arm-eabi/bin/../lib/gcc/arm-eabi/6.1.1/../../../../arm-eabi/bin/ld:
internal error
/media/Data/repositories/git/abe/_build/snapshots/binutils-gdb.git~linaro_binutils-2_26-branch/ld/ldlang.c
6299
collect2: error: ld returned 1 exit status
make: *** [GNUmakefile:417:
/media/Data/repositories/git/efidroid/testing/linuxtoolchain/edk2/Build/AppPkg/RELEASE_GCC5/ARM/AppPkg/Applications/Main/Main/DEBUG/Main.dll]
Error 1
Not sure what's going on here ...

Also, I only did compilation tests, I didn't try to run any of the produced
binaries.

this is the fixed branch:
https://github.com/M1cha/edk2/commits/edk2-master-gcc6
it's based on your gcc5-lto-v6 branch.
Thanks for the report. I will look into this.


Michael Zimmermann
 

sry but I have to retest everything since I aciidentally checked out a
wrong revision.
will report back later.
ignore this, everything in my report was correct. got confused with
CommitDate vs AuthorDate.

Only 0x4 or 0x9 or others as well? This is relevent since 0x4 is a PLT
relocation which can be fixed up easily. The GOT based ones are
trickier since they involve a GOT entry with an absolute symbol
address that needs to be fixed up by the PE/COFF loader

Only 0x4.

Interesting. I wonder where the first memmove resp. memset are coming
from. Are you linking with libgcc are sth like that?

I was able to fix memmove with this patch:

diff --git a/ArmPkg/Library/CompilerIntrinsicsLib/Arm/memmove.S
b/ArmPkg/Library/CompilerIntrinsicsLib/Arm/memmove.S
index 79f95b0..5833814 100644
--- a/ArmPkg/Library/CompilerIntrinsicsLib/Arm/memmove.S
+++ b/ArmPkg/Library/CompilerIntrinsicsLib/Arm/memmove.S
@@ -14,7 +14,6 @@

.text
.align 2
- GCC_ASM_EXPORT (memmove)

# VOID
# EFIAPI


no idea about memset, but when I hacked it away by just removing the export
from the CompilerIntrinsicsLib, the error was gone, but the 'plugin needed
to handle lto object' errors were still there.

Thanks
Michael


On Tue, Aug 2, 2016 at 4:46 PM, Michael Zimmermann <sigmaepsilon92@gmail.com
wrote:
sry but I have to retest everything since I aciidentally checked out a
wrong revision.
will report back later.

On Tue, Aug 2, 2016 at 4:39 PM, Michael Zimmermann <
sigmaepsilon92@gmail.com> wrote:

Sry for the late reply but I tried your latest gcc-lto branch to make
sure my answers are still correct.
I tested it with all configurations(StdLib:X64/ARM, Ovmf:X64,
ArmVirtPkg:ARM with both RELEASE and DEBUG).
In StdLib are many warnings actually. That's because
of -Wunused-const-variable and -Wmisleading-indentation.
Also I had to apply the commit to fix 'Unsupported ELF EM_X86_64
relocation 0x4.' for X64.

'-b RELEASE -a ARM -t GCC5 -p AppPkg/AppPkg.dsc' is the only
configuration I can't get to compile with gcc6(DEBUG works):
/tmp/ccYJi1bO.ltrans0.ltrans.o: In function `memmove':
<artificial>:(.text+0x3670): multiple definition of `memmove'
/media/Data/repositories/git/efidroid/testing/linuxtoolchain/edk2/Build/AppPkg/RELEASE_GCC5/ARM/ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib/OUTPUT/CompilerIntrinsicsLib.lib(memmove.obj):(.text+0x0):
first defined here
/tmp/ccYJi1bO.ltrans0.ltrans.o: In function `memset':
<artificial>:(.text+0x3674): multiple definition of `memset'
/media/Data/repositories/git/efidroid/testing/linuxtoolchain/edk2/Build/AppPkg/RELEASE_GCC5/ARM/ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib/OUTPUT/CompilerIntrinsicsLib.lib(memset.obj):(.text+0x10):
first defined here

/media/Data/repositories/git/efidroid/prebuilts/gcc/linux-x86/arm/gcc-linaro-6.1.1~linaro-gcc-6-branch@f3888e76-20160721-x86_64_arm-eabi/bin/../lib/gcc/arm-eabi/6.1.1/../../../../arm-eabi/bin/ld:
printf.obj: plugin needed to handle lto object

/media/Data/repositories/git/efidroid/prebuilts/gcc/linux-x86/arm/gcc-linaro-6.1.1~linaro-gcc-6-branch@f3888e76-20160721-x86_64_arm-eabi/bin/../lib/gcc/arm-eabi/6.1.1/../../../../arm-eabi/bin/ld:
puts.obj: plugin needed to handle lto object

/media/Data/repositories/git/efidroid/prebuilts/gcc/linux-x86/arm/gcc-linaro-6.1.1~linaro-gcc-6-branch@f3888e76-20160721-x86_64_arm-eabi/bin/../lib/gcc/arm-eabi/6.1.1/../../../../arm-eabi/bin/ld:
internal error
/media/Data/repositories/git/abe/_build/snapshots/binutils-gdb.git~linaro_binutils-2_26-branch/ld/ldlang.c
6299
collect2: error: ld returned 1 exit status
make: *** [GNUmakefile:417:
/media/Data/repositories/git/efidroid/testing/linuxtoolchain/edk2/Build/AppPkg/RELEASE_GCC5/ARM/AppPkg/Applications/Main/Main/DEBUG/Main.dll]
Error 1

Also, I only did compilation tests, I didn't try to run any of the
produced binaries.

this is the fixed branch:
https://github.com/M1cha/edk2/commits/edk2-master-gcc6
it's based on your gcc5-lto-v6 branch.

Thanks
Michael

On Tue, Aug 2, 2016 at 3:56 PM, Ard Biesheuvel <ard.biesheuvel@linaro.org
wrote:
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?