From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by mx.groups.io with SMTP id smtpd.web10.5003.1570709901457526048 for ; Thu, 10 Oct 2019 05:18:21 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.136, mailfrom: liming.gao@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Oct 2019 05:18:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,280,1566889200"; d="scan'208";a="198331450" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga006.jf.intel.com with ESMTP; 10 Oct 2019 05:18:20 -0700 Received: from shsmsx106.ccr.corp.intel.com (10.239.4.159) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 10 Oct 2019 05:18:19 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.166]) by SHSMSX106.ccr.corp.intel.com ([169.254.10.119]) with mapi id 14.03.0439.000; Thu, 10 Oct 2019 20:18:17 +0800 From: "Liming Gao" To: "devel@edk2.groups.io" , "lersek@redhat.com" , Andrew Fish CC: "Justen, Jordan L" Subject: Re: [edk2-devel] [Patch 11/12] OvmfPkg: Enable CLANG9 tool chain - Thread-Topic: [edk2-devel] [Patch 11/12] OvmfPkg: Enable CLANG9 tool chain - Thread-Index: AQHVfr3RLjT+k9ssYEKwbpGDnOmlwqdS9t4AgADTQLA= Date: Thu, 10 Oct 2019 12:18:17 +0000 Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14E51572A@SHSMSX104.ccr.corp.intel.com> References: <1569570395-11240-1-git-send-email-liming.gao@intel.com> <1569570395-11240-12-git-send-email-liming.gao@intel.com> <4c27bdc4-60b4-26bf-c416-c02b69ef8051@redhat.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E5124FA@SHSMSX104.ccr.corp.intel.com> <7fc791fe-9d08-9763-ecc9-529e88b621c6@redhat.com> <767711D5-7C33-4703-8E97-F4F5B5A6BD5F@apple.com> <6f49899d-b5e4-70ad-82e5-08c5a8649ac8@redhat.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E514EAB@SHSMSX104.ccr.corp.intel.com> <1e3de9da-1218-588a-4632-0263d6f64de5@redhat.com> In-Reply-To: <1e3de9da-1218-588a-4632-0263d6f64de5@redhat.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzdiNDVhZDktNmM3Mi00ZDU0LWIzNTUtMTUwZTRlZjNjZDhiIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoidTFVOFBBSDViVmR5Yms1VEtxWThhUGhTcGR5Q3poVDkzQnQ5TkI4enpYNFRLYUxKdXFUZGRoSlM4YXlrdGZveSJ9 dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: liming.gao@intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: devel@edk2.groups.io On Behalf Of Laszlo Er= sek > Sent: Thursday, October 10, 2019 3:35 PM > To: Andrew Fish ; Gao, Liming > Cc: devel@edk2.groups.io > Subject: Re: [edk2-devel] [Patch 11/12] OvmfPkg: Enable CLANG9 tool chai= n - >=20 > Hi Andrew, >=20 > On 10/09/19 18:22, Andrew Fish wrote: >=20 > > I thought the thing we were discussing was compiler flags. > > Specifically -mno-mmx -mno-sse. It seems to me if OVMF requires > > -mno-mmx -mno-sse then it is a bug in the tools_def.txt definition > > for those compilers? As far as I can tell -mno-implicit-float should > > prevent the optimizer from using floating point. The -mno-mmx > > -mno-sse flags most change how floating point code gets compiled [1]. > > it looks like -mno-mmx -mno-sse just down grade floating point > > instructions that get used. Thus it seems like either we have some > > code doing float and that code should set -mno-mmx -mno-sse, or the > > -mno-mmx -mno-sse should be set generically. >=20 > The origin of those build flags in OVMF is commit 4a8266f570ef > ("OvmfPkg: Work around issue seen with kvm + grub2 (efi)", 2010-12-31): >=20 > OvmfPkg: Work around issue seen with kvm + grub2 (efi) >=20 > When OVMF is run with kvm and grub2 (efi), an exception > occurs when mmx/sse registers are accessed. >=20 > As a work around, this change eliminates firmware usage > of these register types. >=20 > First, only the BaseMemoryLib implementation > MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf > is used. >=20 > Second, the GCC compiler is passes the additional > '-mno-mmx -mno-sse' parameters. >=20 > The eternal problem with this kind of workaround is that we never know > when it becomes safe to remove. >=20 > It would be nice to understand the exact details around the problem. > Given that the commit is from 2010, I assume the issue is difficult to > reproduce with recent components (KVM, grub2). On the other hand, if we > just remove the flags (which we should, in a perfect world), someone > could report a bug in three months: "my host distro upgraded the OVMF > package to the next edk2-stableYYYYMM tag, and now my virtual machine, > which runs a distro from 2009, no longer boots". (We've seen similar > reports before.) Yes. I agree it is hard to decide to remove this option, because we don't = know its impact.=20 With the option -mno-mmx -mno-sse, it will cause CLANG9 linker failure lik= e below. So, I say=20 this patch is to support the different linker. 0. Program arguments: C:\Program Files\LLVM\bin\lld-link.EXE /OUT:d:\= allpkg\edk2\Build\Ovmf3264\DEBUG_CLANG9\X64\Se curityPkg\VariableAuthenticated\SecureBootConfigDxe\SecureBootConfigDxe\DE= BUG\SecureBootConfigDxe.dll /NOLOGO /NODEFAULT LIB /IGNORE:4001 /OPT:REF /OPT:ICF=3D10 /ALIGN:32 /FILEALIGN:32 /SECTION:.= xdata,D /SECTION:.pdata,D /Machine:X64 /DLL /ENT RY:_ModuleEntryPoint /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:= 0 /DEBUG:GHASH /lldmap @d:\allpkg\edk2\Build\O vmf3264\DEBUG_CLANG9\X64\SecurityPkg\VariableAuthenticated\SecureBootConfi= gDxe\SecureBootConfigDxe\OUTPUT\static_library _files.lst 1. Running pass 'Function Pass Manager' on module 'ld-temp.o'. 2. Running pass 'X86 FP Stackifier' on function '@drbg_add' #0 0x00007ff696bad7f8 C:\Program Files\LLVM\bin\lld-link.EXE 0x148d7f8 C:= \Program Files\LLVM\bin\lld-link.EXE 0x142ba7f Thanks Liming >=20 > Thanks > Laszlo >=20 >=20