Ard:
  Another information. I try Steven change in 
https://github.com/shijunjing/edk2/tree/llvm_v2. With his patch, build -p 
OvmfPkg/OvmfPkgIa32X64.dsc -t GCC5 -DSECURE_BOOT_ENABLE=TRUE -a IA32 -a X64 can 
pass build. 

Thanks
Liming
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Gao, Liming
> Sent: Monday, July 25, 2016 10:12 PM
> To: Ard Biesheuvel <ard.biesheu...@linaro.org>
> Cc: Justen, Jordan L <jordan.l.jus...@intel.com>; edk2-devel@lists.01.org;
> ler...@redhat.com; leif.lindh...@linaro.org
> Subject: Re: [edk2] [PATCH v3 0/6] BaseTools: add support for GCC5 in LTO
> mode
> 
> Without -DSECURE_BOOT_ENABLE=TRUE, OVMF on GCC5 in LTO mode can
> pass build.
> 
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ard Biesheuvel
> Sent: Monday, July 25, 2016 10:04 PM
> To: Gao, Liming <liming....@intel.com>
> Cc: Justen, Jordan L <jordan.l.jus...@intel.com>; edk2-devel@lists.01.org;
> leif.lindh...@linaro.org; ler...@redhat.com
> Subject: Re: [edk2] [PATCH v3 0/6] BaseTools: add support for GCC5 in LTO
> mode
> 
> 
> > On 25 jul. 2016, at 15:21, Gao, Liming wrote:
> >
> > Ard:
> > After apply these patches, I try to build OvmfPkg with SECURE enable on
> GCC5 in LTO mode.
> 
> 
> Did you also try it without?
> 
> > It reports build failure. Have you tried such build before?
> >
> 
> No I have not.
> 
> > Build command: build -p OvmfPkg/OvmfPkgIa32X64.dsc -t GCC5 -
> DSECURE_BOOT_ENABLE=TRUE -a IA32 -a X64
> > Build error message, seemly OpenSsl can't be linked with LTO.
> >
> 
> I will investigate. It indeed looks like an incompatibility with lto, I 
> should check
> whether Arm is affected as well.
> 
> Thanks,
> Ard.
> 
> > "gcc" -o
> /home/hwu/work/lgao4/AllPkg/Build/Ovmf3264/DEBUG_GCC5/X64/MdeM
> odulePkg/Universal/SecurityStubDxe/SecurityStubDxe/DEBUG/SecurityStub
> Dxe.dll -nostdlib -Wl,-n,-q,--gc-sections -z common-page-size=0x40 -Wl,--
> entry,_ModuleEntryPoint -u _ModuleEntryPoint -Wl,-
> Map,/home/hwu/work/lgao4/AllPkg/Build/Ovmf3264/DEBUG_GCC5/X64/M
> deModulePkg/Universal/SecurityStubDxe/SecurityStubDxe/DEBUG/Security
> StubDxe.map -Wl,-melf_x86_64,--oformat=elf64-x86-64 -Wl,--start-
> group,@/home/hwu/work/lgao4/AllPkg/Build/Ovmf3264/DEBUG_GCC5/X64
> /MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe/OUTPUT/stat
> ic_library_files.lst,--end-group -Wl,--defsym=PECOFF_HEADER_SIZE=0x228 -
> Wl,--
> script=/home/hwu/work/lgao4/AllPkg/edk2/BaseTools/Scripts/GccBase.lds
> > /tmp/cc9uBgrd.ltrans0.ltrans.o: In function `DxeImageVerificationHandler':
> > :(.text+0x1f13): undefined reference to `malloc'
> > :(.text+0x1f7a): undefined reference to `free'
> > :(.text+0x1f92): undefined reference to `malloc'
> > :(.text+0x1fb9): undefined reference to `free'
> > :(.text+0x1fe3): undefined reference to `free'
> > :(.text+0x2027): undefined reference to `malloc'
> > :(.text+0x20bf): undefined reference to `free'
> > :(.text+0x2116): undefined reference to `free'
> > :(.text+0x212d): undefined reference to `free'
> > :(.text+0x213a): undefined reference to `free'
> > :(.text+0x21f7): undefined reference to `free'
> > /tmp/cc9uBgrd.ltrans0.ltrans.o::(.text+0x2204): more undefined
> references to `free' follow
> > /tmp/cc9uBgrd.ltrans8.ltrans.o: In function
> `default_realloc_ex.lto_priv.190':
> > :(.text+0x1): undefined reference to `realloc'
> > /tmp/cc9uBgrd.ltrans8.ltrans.o: In function
> `default_malloc_ex.lto_priv.187':
> > :(.text+0x6): undefined reference to `malloc'
> > /tmp/cc9uBgrd.ltrans8.ltrans.o: In function `CRYPTO_free':
> > :(.text+0x613): undefined reference to `free'
> > /tmp/cc9uBgrd.ltrans8.ltrans.o: In function `WrapPkcs7Data':
> > :(.text.unlikely+0x72): undefined reference to `malloc'
> > /tmp/cc9uBgrd.ltrans17.ltrans.o: In function `OPENSSL_gmtime':
> > :(.text+0x176a): undefined reference to `malloc'
> > /tmp/cc9uBgrd.ltrans18.ltrans.o: In function `RSA_free':
> > :(.text+0x123a): undefined reference to `free'
> > /tmp/cc9uBgrd.ltrans20.ltrans.o: In function `qsort':
> > :(.text+0x1368): undefined reference to `malloc'
> > :(.text+0x13bc): undefined reference to `malloc'
> > :(.text+0x13b4): undefined reference to `free'
> > /tmp/cc9uBgrd.ltrans27.ltrans.o: In function
> `CRYPTO_realloc_clean.constprop.153':
> > :(.text+0x20e): undefined reference to `free'
> > /tmp/cc9uBgrd.ltrans27.ltrans.o:(.data.rel.ro.local+0x578): undefined
> reference to `free'
> > /usr/bin/ld:
> /home/hwu/work/lgao4/AllPkg/Build/Ovmf3264/DEBUG_GCC5/X64/MdeM
> odulePkg/Universal/SecurityStubDxe/SecurityStubDxe/DEBUG/SecurityStub
> Dxe.dll: protected symbol `realloc' isn't defined
> > /usr/bin/ld: final link failed: Bad value
> > collect2: error: ld returned 1 exit status
> > make: ***
> [/home/hwu/work/lgao4/AllPkg/Build/Ovmf3264/DEBUG_GCC5/X64/MdeM
> odulePkg/Universal/SecurityStubDxe/SecurityStubDxe/DEBUG/SecurityStub
> Dxe.dll] Error 1
> >
> >
> > build.py...
> > : error 7000: Failed to execute command
> > make tbuild
> [/home/hwu/work/lgao4/AllPkg/Build/Ovmf3264/DEBUG_GCC5/X64/MdeM
> odulePkg/Universal/SecurityStubDxe/SecurityStubDxe]
> >
> >
> > build.py...
> > : error F002: Failed to build module
> >
> /home/hwu/work/lgao4/AllPkg/edk2/MdeModulePkg/Universal/SecuritySt
> ubDxe/SecurityStubDxe.inf [X64, GCC5, DEBUG]
> >
> > Thanks
> > Liming
> >> -----Original Message-----
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> >> Ard Biesheuvel
> >> Sent: Saturday, July 23, 2016 5:03 PM
> >> To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>;
> ler...@redhat.com<mailto:ler...@redhat.com>; Gao, Liming
> >> ; Shi, Steven ; Zhu,
> >> Yonghong ; Justen, Jordan L
> >>
> >> Cc: leif.lindh...@linaro.org<mailto:leif.lindh...@linaro.org>; Ard
> Biesheuvel
> >> Subject: [edk2] [PATCH v3 0/6] BaseTools: add support for GCC5 in LTO
> mode
> >>
> >> This v3 to introduce GCC5 is now a 6 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 v2:
> >> - add license headers to LTO glue files for ARM and AARCH64 (#5)
> >> - get rid of lto-ld-wrapper script
> >>
> >> Ard Biesheuvel (6):
> >> 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: 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 ++++++++++++++------
> >> EmulatorPkg/Unix/Host/Host.inf | 6 +-
> >> 9 files changed, 366 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<mailto:edk2-devel@lists.01.org>
> >> https://lists.01.org/mailman/listinfo/edk2-devel
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Reply via email to