From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mx.groups.io with SMTP id smtpd.web09.1226.1605252944262070792 for ; Thu, 12 Nov 2020 23:35:44 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: arm.com, ip: 217.140.110.172, mailfrom: ard.biesheuvel@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 278FD142F; Thu, 12 Nov 2020 23:35:43 -0800 (PST) Received: from [192.168.1.81] (unknown [10.37.8.79]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5F18B3F718; Thu, 12 Nov 2020 23:35:41 -0800 (PST) Subject: Re: [edk2-devel] [PATCH v5 0/2] CryptoPkg/OpensslLib: Add native instruction support for X64 To: "Zurcher, Christopher J" , "devel@edk2.groups.io" , "lersek@redhat.com" , "Yao, Jiewen" Cc: gaoliming , "Wang, Jian J" , "Lu, XiaoyuX" , "Kinney, Michael D" References: <20201103215834.7533-1-christopher.j.zurcher@intel.com> <7D73B5FD-CBCA-4E8C-B73B-930722C9FCF7@intel.com> <903654d9-f903-734c-1d07-2f83a8c40099@redhat.com> <8bb817f1-d473-467a-f33e-a3c22a79528b@redhat.com> <1646ECAE89844BF6.31886@groups.io> From: "Ard Biesheuvel" Message-ID: Date: Fri, 13 Nov 2020 08:35:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 11/13/20 3:28 AM, Zurcher, Christopher J wrote: > Laszlo and Ard, > In the description for commit 214a3b79417f it says "disabling it by default, and re-enabling it explicitly for packages > that depend on it." > Is there a documented process to re-enable the COMMON keyword for a particular package? Is this even possible? > Adding -fcommon on the GCC command line should re-enable it, and you should be able to do that in package scope. It might mean we'd have to move *(COMMON) out of the discards section though. However, as the commit log explains, COMMON allocation is a *bad* idea for highly granular code bases such as EDK2, since it merges variables based on their names only. Do you have any idea why the command line options we use to build OpenSSL are not preventing these COMMON sections from being emitted? >> -----Original Message----- >> From: devel@edk2.groups.io On Behalf Of Zurcher, >> Christopher J >> Sent: Thursday, November 12, 2020 17:22 >> To: devel@edk2.groups.io; lersek@redhat.com; Yao, Jiewen >> >> Cc: gaoliming ; Wang, Jian J >> ; Lu, XiaoyuX ; Kinney, Michael >> D ; Ard Biesheuvel >> Subject: Re: [edk2-devel] [PATCH v5 0/2] CryptoPkg/OpensslLib: Add native >> instruction support for X64 >> >> Sorry for the thrash on this; in testing the GCC build with .S files, I found >> that there is still a build failure due to the inclusion of a "common" data >> section in the OpenSSL code, which is explicitly removed by Base Tools >> changes in commit 214a3b79417f. So I think without removing this restriction >> or changing OpenSSL in a future patch, we will not be able to build the >> accelerated functions for GCC. >> >> Thanks, >> Christopher Zurcher >> >>> -----Original Message----- >>> From: devel@edk2.groups.io On Behalf Of Laszlo Ersek >>> Sent: Wednesday, November 11, 2020 11:09 >>> To: Yao, Jiewen ; Zurcher, Christopher J >>> >>> Cc: devel@edk2.groups.io; gaoliming ; Wang, Jian >> J >>> ; Lu, XiaoyuX ; Kinney, >> Michael >>> D ; Ard Biesheuvel >>> Subject: Re: [edk2-devel] [PATCH v5 0/2] CryptoPkg/OpensslLib: Add native >>> instruction support for X64 >>> >>> On 11/11/20 03:19, Yao, Jiewen wrote: >>>> I full agree with long term plan. E.g. we need remove ApiHook.c as well. >>>> >>>> I more concern about the short term plan, if you want to check in this >> and >>> get the capability. >>>> >>>> I think we need this capability for GCC tool chain as well, so I am OK to >>> check in .S. >>>> This is auto generated. I do not think it is a step back. >>>> >>>> We can remove them together with ApiHook later, in the long term. >>> >>> Agreed on all counts. >>> >>> Laszlo >>> >>> >>> >>> >>> >> >> >> >> >> >