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:ler...@redhat.com]
> Sent: Friday, August 11, 2017 7:18 PM
> To: Shi, Steven <steven....@intel.com>; edk2-devel-01 <edk2-
> de...@lists.01.org>
> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>; Justen, Jordan L
> <jordan.l.jus...@intel.com>; Gao, Liming <liming....@intel.com>; Kinney,
> Michael D <michael.d.kin...@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
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
