回复: [edk2-devel] [PATCH v5 0/2] CryptoPkg/OpensslLib: Add native instruction support for X64

gaoliming gaoliming at byosoft.com.cn
Tue Nov 10 14:28:43 UTC 2020


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. 

Thanks
Liming
> -----邮件原件-----
> 发件人: Laszlo Ersek <lersek at redhat.com>
> 发送时间: 2020年11月10日 20:31
> 收件人: Yao, Jiewen <jiewen.yao at intel.com>; Zurcher, Christopher J
> <christopher.j.zurcher at intel.com>
> 抄送: devel at edk2.groups.io; gaoliming <gaoliming at byosoft.com.cn>; Wang,
> Jian J <jian.j.wang at intel.com>; Lu, XiaoyuX <xiaoyux.lu at intel.com>; Kinney,
> Michael D <michael.d.kinney at intel.com>; Ard Biesheuvel
> <ard.biesheuvel at arm.com>
> 主题: Re: [edk2-devel] [PATCH v5 0/2] CryptoPkg/OpensslLib: Add native
> instruction support for X64
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> Thanks
> Laszlo





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#67229): https://edk2.groups.io/g/devel/message/67229
Mute This Topic: https://groups.io/mt/78160109/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-






More information about the edk2-devel-archive mailing list