From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.byosoft.com.cn (mail.byosoft.com.cn [58.240.74.242]) by mx.groups.io with SMTP id smtpd.web09.28492.1605018535299996076 for ; Tue, 10 Nov 2020 06:28:58 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=none, err=permanent DNS error (domain: byosoft.com.cn, ip: 58.240.74.242, mailfrom: gaoliming@byosoft.com.cn) Received: from DESKTOPS6D0PVI ([116.232.42.12]) (envelope-sender ) by 192.168.6.13 with ESMTP for ; Tue, 10 Nov 2020 22:28:45 +0800 X-WM-Sender: gaoliming@byosoft.com.cn X-WM-AuthFlag: YES X-WM-AuthUser: gaoliming@byosoft.com.cn From: "gaoliming" To: "'Laszlo Ersek'" , "'Yao, Jiewen'" , "'Zurcher, Christopher J'" Cc: , "'Wang, Jian J'" , "'Lu, XiaoyuX'" , "'Kinney, Michael D'" , "'Ard Biesheuvel'" References: <20201103215834.7533-1-christopher.j.zurcher@intel.com> <1644D590FF4B7423.25549@groups.io> <7D73B5FD-CBCA-4E8C-B73B-930722C9FCF7@intel.com> <903654d9-f903-734c-1d07-2f83a8c40099@redhat.com> In-Reply-To: <903654d9-f903-734c-1d07-2f83a8c40099@redhat.com> Subject: =?UTF-8?B?5Zue5aSNOiBbZWRrMi1kZXZlbF0gW1BBVENIIHY1IDAvMl0gQ3J5cHRvUGtnL09wZW5zc2xMaWI6IEFkZCBuYXRpdmUgaW5zdHJ1Y3Rpb24gc3VwcG9ydCBmb3IgWDY0?= Date: Tue, 10 Nov 2020 22:28:43 +0800 Message-ID: <00e301d6b76d$cb4fc810$61ef5830$@byosoft.com.cn> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQERaLGbq5oCWXT0P0IWAbMRODnZFAIa4adAAjEIJzkBIylStwGAJpolAY5KELgCfygX7wK6f+QsATWJoTYCqasnxaq/VJnQ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: zh-cn Laszlo: Those assembly files are auto generated from openssl. Now, the = generated nasm files use the syntax for win64 object only. So, they = can't be used for GCC and XCODE. Zurcher mentions GAS assembly files can also be generated. If there is = the issue in them, they can be re-generated together when edk2 updates = to new openssl version. So, there is no additional maintain effort for = them.=20 Thanks Liming > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Laszlo Ersek > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2020=E5=B9=B411=E6=9C=8810=E6=97=A5 20:31 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Yao, Jiewen ; = Zurcher, Christopher J > > =E6=8A=84=E9=80=81: devel@edk2.groups.io; gaoliming = ; Wang, > Jian J ; Lu, XiaoyuX ; = Kinney, > Michael D ; Ard Biesheuvel > > =E4=B8=BB=E9=A2=98: Re: [edk2-devel] [PATCH v5 0/2] = CryptoPkg/OpensslLib: Add native > instruction support for X64 >=20 > On 11/07/20 03:24, Yao, Jiewen wrote: > > The reason we choose NASM is that we can use same assembly in = windows > build and Linux build. However if this NASM cannot be used in Linux, = then the > benefit does not exist any more. You can generate GAS to support GCC = build, > and check in .S file. >=20 > I disagree with this idea. To me (as an exclusive GCC user), = uniformity > of assembly files is *much* more important than getting native > instruction support in OpenSSL with all toolchains at the exact same = time. >=20 > If we enable native instruction support for (a) VS and CLANGPDB now, = and > (b) for GCC later, then that's two steps, with each step being in the > forward direction. Performing just (a) for now creates no technical > debt. A feature gap is not technical debt; you cannot mistake a = missing > feature for a working feature. >=20 > If we re-add .S files now, for whatever purpose, that's a step *back*, > however. It creates technical debt. A working feature on an invalid > basis *can* be mistaken for a working feature, and we shouldn't do = that > (unless there are strong business needs for some participants, *AND* = we > have a *very specific* plan and timeline for backing out the hack). I > really don't have any trust in technical debt being "paid" in edk2 > anytime soon, though. >=20 > Thanks > Laszlo