Re: [PATCH v4 0/7] BaseTools: add support for GCC5 in LTO mode

[Jordan Justen <jordan.l.justen@intel.com>]

On 2016-07-28 23:09:15, Ard Biesheuvel wrote:
> On 29 July 2016 at 06:47, Gao, Liming <liming.gao@intel.com> wrote:
> > Ard:
> >   Thanks for your update. I have some comments for them.
> > 1) It uses GCC as Link for GCC44-GCC49. Have you done verification on them? I verify GCC49 in OVMFIa32X64 platform. It works.
> 
> Yes, I tested all of them.
> 

I tested GCC44 (X64) on an old live-cd where GCC 4.4 was the supported
version. OVMF built and booted UEFI Linux. Therefore, I don't think we
are likely to have a major issue with GCC44-GCC49.

I also tested GCC49 and GCC5 with X64 on a system with GCC 5.4. It
built and booted UEFI Linux.

Can you add something like 'added GCC5 toolchain' into the subject for
patch 7? I really think that a patch that adds a new toolchain should
make it immediately obvious in the subject line.

3, 4 & 7 Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

The others, Acked-by: Jordan Justen <jordan.l.justen@intel.com>

> > 2) After this change, how to append new link option in platform DSC? Use style -Wl, ?
> 
> It depends. Some options (like -z) don't need it, but others do.
> 
> > 3) I see GCC5 uses gcc-ar as its SLINK, and GCC49 uses ar as its SLINK. Is gcc-ar required only by LTO?
> 
> Yes
> 
> > 4) Before GCC49 optimization, GCC49 means GCC49 or later, GCC5 can work with GCC49 tool chain configuration. But now, I configure gcc to point to GCC5, and build OVMF with GCC49 tool chain, it reports GenFw failure. I expect GCC5 work with GCC49 and GCC5 tool chain both. GCC49 for no lto, GCC5 for lto. I know Steven has provided the patch to fix this GenFw issue.
> >
> > GenFw: ERROR 3000: Invalid
> >   /home/hwu/work/lgao4/AllPkg/Build/Ovmf3264/DEBUG_GCC49/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll unsupported ELF EM_X86_64 relocation 0x9.
> > GenFw: ERROR 3000: Invalid
> >   /home/hwu/work/lgao4/AllPkg/Build/Ovmf3264/DEBUG_GCC49/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll unsupported ELF EM_X86_64 relocation 0x9.
> > GenFw: ERROR 3000: Invalid
> >
> 
> Which GCC version are you using?
> 
> 
> >> -----Original Message-----
> >> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> >> Sent: Wednesday, July 27, 2016 7:14 PM
> >> To: edk2-devel@lists.01.org; lersek@redhat.com; Gao, Liming
> >> <liming.gao@intel.com>; Shi, Steven <steven.shi@intel.com>; Zhu,
> >> Yonghong <yonghong.zhu@intel.com>; Justen, Jordan L
> >> <jordan.l.justen@intel.com>
> >> Cc: leif.lindholm@linaro.org; Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >> Subject: [PATCH v4 0/7] BaseTools: add support for GCC5 in LTO mode
> >>
> >> This v4 to introduce GCC5 is now a 7 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 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 (7):
> >>   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
> >>   BaseTools GCC: add support for 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                   | 344 ++++++++++++++------
> >>  BaseTools/Scripts/GccBase.lds                       |   6 +
> >>  EmulatorPkg/Unix/Host/Host.inf                      |   6 +-
> >>  10 files changed, 372 insertions(+), 108 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
> >
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel