Re: [PATCH 1/1] BaseTools/tools_def.template: revert to large code model for X64/GCC5/LTO

["Shi, Steven" <steven.shi@intel.com>]

OK. I can reproduce the failure with -smp 4 and -m 5120 in my side. 
It looks a linker bug about assemble function support in PIC/PIE code.  You know, if we only have C code, the compiler/linker will generate all the machine code and guarantee all the address reference are position independent under PIC/PIE build. But if we mix manually written assemble code in the C code,  the linker cannot really control the address reference in the assemble code, and  might got confused. So, it is not seldom we could see the compiler/linker generate wrong code for mixed code,  especially with very high level optimization, e.g. LTO.

Globally change memory model from small to large will bring not trivial impact (+15%) to code size, espcial for the uncomperssed option rom dirver. Below is some data of OvmfPkgX64.dsc platform.
		Dxecore.efi 	CpuDxe.efi	CpuMpPei	PeiCore.efi
Small+PIE: 	139520		47360		30144		46720
Large:		165696		55360		34496		53504

A simpler workaround could be to add a C function wrapper around the assemble lib function as below. This simple workaround works in my side.  But it is necessary to find this issue's root cause and fix it in the compiler/linker. I will try to raise this issue to compiler/linker guys.

diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c b/UefiCpuPkg/Library/MpInitLib/MpLib.c
old mode 100644
new mode 100755
index a3eea29..7afe434
--- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
@@ -738,6 +738,15 @@ WaitApWakeup (
   }
 }

+VOID
+EFIAPI
+InitializeFloatingPointUnitsWrapper (
+  VOID
+  )
+{
+  InitializeFloatingPointUnits();
+}
+
 /**
   This function will fill the exchange info structure.

@@ -771,7 +780,7 @@ FillExchangeInfoData (

   ExchangeInfo->EnableExecuteDisable = IsBspExecuteDisableEnabled ();

-  ExchangeInfo->InitializeFloatingPointUnitsAddress = (UINTN)InitializeFloatingPointUnits;
+  ExchangeInfo->InitializeFloatingPointUnitsAddress = (UINTN)InitializeFloatingPointUnitsWrapper;

   //
   // Get the BSP's data of GDT and IDT


Steven Shi
Intel\SSG\STO\UEFI Firmware

Tel: +86 021-61166522
iNet: 821-6522

> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Friday, August 11, 2017 7:18 PM
> To: Shi, Steven <steven.shi@intel.com>; edk2-devel-01 <edk2-
> devel@lists.01.org>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Justen, Jordan L
> <jordan.l.justen@intel.com>; Gao, Liming <liming.gao@intel.com>; Kinney,
> Michael D <michael.d.kinney@intel.com>
> Subject: Re: [edk2] [PATCH 1/1] BaseTools/tools_def.template: revert to large
> code model for X64/GCC5/LTO
> 
> Hi Steven,
> 
> On 08/11/17 07:28, Shi, Steven wrote:
> > Hi Laszlo,
> >
> > I'm trying to reproduce your boot failure with OVMF in my Ubuntu
> > system, but not succeed.  My GCC was built from GCC main trunk code
> > in 20170601, and my ld linker is version 2.28. Could you try the ld
> > 2.28 with your gcc-7.1 and check whether it works in your side?  Or,
> > do you know where can I download the gcc-7.1 pre-built binaries?
> This was reproduced on a stock Fedora 26 installation:
> 
> https://getfedora.org/
> 
> > jshi19@jshi19-desktop:~/wksp_efi/Laszlo/edk2$ build -p
> OvmfPkg/OvmfPkgX64.dsc -t GCC5 -DSECURE_BOOT_ENABLE=TRUE -a X64 -b
> DEBUG  -DDEBUG_ON_SERIAL_PORT -n 5
> >
> > jshi19@jshi19-desktop:~/wksp_efi/Laszlo/edk2$ build -p
> OvmfPkg/OvmfPkgIa32X64.dsc -t GCC5 -DSECURE_BOOT_ENABLE=TRUE -a IA32
> -a X64 -b DEBUG  -DDEBUG_ON_SERIAL_PORT -n 5
> 
> These build commands look good.
> 
> > jshi19@jshi19-
> desktop:~/wksp_efi/Laszlo/edk2/Build/OvmfX64/DEBUG_GCC5/FV$ qemu-
> system-x86_64  -bios OVMF.fd -serial file:serial.log -m 512 -hda fat:. -monitor
> stdio --enable-kvm
> >
> > jshi19@jshi19-
> desktop:~/wksp_efi/Laszlo/edk2/Build/Ovmf3264/DEBUG_GCC5/FV$ qemu-
> system-x86_64  -bios OVMF.fd -serial file:serial.log -m 512 -hda fat:. -monitor
> stdio --enable-kvm
> 
> The QEMU command lines are missing two options:
> 
> * First, you have to make sure that the VM has enough memory under 4GB
> so that the PEI RAM can grow above the 2GB limit. You are using the
> i440fx board type, so that's OK (its 32-bit memory can go up to 3GB),
> but the "-m" switch is too small. Instead, I recommend:
> 
>   -m 5120
> 
> This will give the VM 5GB of RAM, 3GB of which will be placed under the
> 4GB mark, and 2GB will be placed above.
> 
> * Second, there must be at least one AP (application processor) for
> CpuMpPei to boot up. So please add something like:
> 
>   -smp 4
> 
> Thanks
> Laszlo