From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 84D3F209589F4 for ; Fri, 11 Aug 2017 20:03:00 -0700 (PDT) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga105.fm.intel.com with ESMTP; 11 Aug 2017 20:05:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,361,1498546800"; d="scan'208";a="299260899" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga004.fm.intel.com with ESMTP; 11 Aug 2017 20:05:20 -0700 Received: from fmsmsx121.amr.corp.intel.com (10.18.125.36) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 11 Aug 2017 20:05:20 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by fmsmsx121.amr.corp.intel.com (10.18.125.36) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 11 Aug 2017 20:05:20 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.183]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.135]) with mapi id 14.03.0319.002; Sat, 12 Aug 2017 11:05:18 +0800 From: "Shi, Steven" To: Laszlo Ersek , edk2-devel-01 , Alex Williamson CC: Ard Biesheuvel , "Justen, Jordan L" , "Gao, Liming" , "Kinney, Michael D" Thread-Topic: [edk2] [PATCH 1/1] BaseTools/tools_def.template: revert to large code model for X64/GCC5/LTO Thread-Index: AQHTEjmj11tzzVXSNkSM0oM1tV6CHqJ+mHLg///j+oCAALWoQA== Date: Sat, 12 Aug 2017 03:05:17 +0000 Message-ID: <06C8AB66E78EE34A949939824ABE2B313B56176B@shsmsx102.ccr.corp.intel.com> References: <20170811003426.2332-1-lersek@redhat.com> <20170811003426.2332-2-lersek@redhat.com> <06C8AB66E78EE34A949939824ABE2B313B560EB2@shsmsx102.ccr.corp.intel.com> <787f4528-980e-8c71-2804-0e8be2c935aa@redhat.com> In-Reply-To: <787f4528-980e-8c71-2804-0e8be2c935aa@redhat.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: [PATCH 1/1] BaseTools/tools_def.template: revert to large code model for X64/GCC5/LTO X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 03:03:00 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OK. I can reproduce the failure with -smp 4 and -m 5120 in my side.=20 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 ma= chine 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 assem= ble code, and might got confused. So, it is not seldom we could see the co= mpiler/linker generate wrong code for mixed code, especially with very hig= h level optimization, e.g. LTO. Globally change memory model from small to large will bring not trivial imp= act (+15%) to code size, espcial for the uncomperssed option rom dirver. Be= low 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 assemb= le 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/lin= ker. I will try to raise this issue to compiler/linker guys. diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c b/UefiCpuPkg/Library/MpIn= itLib/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 =3D IsBspExecuteDisableEnabled (); - ExchangeInfo->InitializeFloatingPointUnitsAddress =3D (UINTN)InitializeF= loatingPointUnits; + ExchangeInfo->InitializeFloatingPointUnitsAddress =3D (UINTN)InitializeF= loatingPointUnitsWrapper; // // 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 ; edk2-devel-01 devel@lists.01.org> > Cc: Ard Biesheuvel ; Justen, Jordan L > ; Gao, Liming ; Kinney, > Michael D > Subject: Re: [edk2] [PATCH 1/1] BaseTools/tools_def.template: revert to l= arge > code model for X64/GCC5/LTO >=20 > Hi Steven, >=20 > 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: >=20 > https://getfedora.org/ >=20 > > jshi19@jshi19-desktop:~/wksp_efi/Laszlo/edk2$ build -p > OvmfPkg/OvmfPkgX64.dsc -t GCC5 -DSECURE_BOOT_ENABLE=3DTRUE -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=3DTRUE -a IA32 > -a X64 -b DEBUG -DDEBUG_ON_SERIAL_PORT -n 5 >=20 > These build commands look good. >=20 > > 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:. -m= onitor > 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:. -m= onitor > stdio --enable-kvm >=20 > The QEMU command lines are missing two options: >=20 > * 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: >=20 > -m 5120 >=20 > This will give the VM 5GB of RAM, 3GB of which will be placed under the > 4GB mark, and 2GB will be placed above. >=20 > * Second, there must be at least one AP (application processor) for > CpuMpPei to boot up. So please add something like: >=20 > -smp 4 >=20 > Thanks > Laszlo