From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web12.10979.1643194974429896028 for ; Wed, 26 Jan 2022 03:02:54 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=TJ5cShKc; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1643194973; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=G3/iEiEVzQt1mxIsWWC+UezoM9ULyevtTsyMUnYP1tQ=; b=TJ5cShKc9HDaA/UxpFsr8xES9Vqin8pnakj6rIA1YFl/8gZOw7OAuI5/rtRXpEFk0Ke5Lt XrND0bvghl1E7JSca4mOoGMRT5zGiClwfERyqhLg4qL1UYGr9piPwgwY4Il5qVq8gtLEGw +3MBsNci3e2e17sjYlBw72MzY5WoTdw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-622-v4-ZT1EiPvWaVq7NrvPpiQ-1; Wed, 26 Jan 2022 06:02:52 -0500 X-MC-Unique: v4-ZT1EiPvWaVq7NrvPpiQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D32D015745; Wed, 26 Jan 2022 11:02:50 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.193.47]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B2009752B7; Wed, 26 Jan 2022 11:02:46 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 8D45E18000AA; Wed, 26 Jan 2022 12:02:44 +0100 (CET) Date: Wed, 26 Jan 2022 12:02:44 +0100 From: "Gerd Hoffmann" To: Pedro Falcato Cc: edk2-devel-groups-io , "Kinney, Michael D" , Kilian Kegel , "Yao, Jiewen" , Sean Brogan , Bret Barkelew , "Wang, Jian J" , "Jiang, Guomin" , Pawel Polawski , "Lu, XiaoyuX" Subject: Re: [edk2-devel] [PATCH 00/24] CryptoPkg/openssl: update openssl submodule to v3.0 Message-ID: <20220126110244.klk24znojvdtirzw@sirius.home.kraxel.org> References: <20211203160748.866150-1-kraxel@redhat.com> <20220117114627.ji5cyqxkca6bmiaf@sirius.home.kraxel.org> <20220121083035.dsqzu3akshonliza@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, > I think adding intrinsic libraries is a mixed bag, for the following > reasons: > > 1) The intrinsic libraries are completely internal to the compilers. > Breaking down that toolchain/code barrier is not a good idea if we want the > project to compile using a good variety of compilers. The API is unstable > (as it's internal to the compiler + version) and sometimes undocumented; > while in reality the ABI doesn't really change (at least in the LLVM/GCC > world, not sure about the other compilers), it's something to consider. Yes. But apparently there is no way around them. We have them for arm. We have them for openssl. IntelUndiPkg in edk2-staging has some too (see IntelUndiPkg/LibC). And I wouldn't be surprised if there are more cases ... Having a policy to outlaw Intrinsics, but then hand out exceptions left and right doesn't look like a good idea to me. I think we should revisit that and accept that there simply is no way around Intrinsics in some cases. I think it makes sense to consolidate all the Intrinsics we have, i.e. move them over to MdePkg, make everybody use that, so we have only a single version to maintain. I think it also makes sense to restrict Intrinsics to the cases where we have no other option, to keep them as small as possible and also make it as easy as possible to maintain them. > 2) Linking the compiler's builtin libraries would fix our issues, except > that it doesn't work in cases where object files are tagged with ABI (such > as hard FP vs soft FP). Also: * On my system the gcc intrinsics are only available as shared library, so the "just unpack the lib and use the object files" idea is not going to work. * I have my doubts that compiler's builtin libraries are optimized for size, so I'd suspect we would see a noticeable size grow from that. * I'd very much prefer to continue with the current approach to have source code for the Intrinsics we need. In case we run into trouble things tend to be much easier to fix when you have the source code at hand. That's actually part of the open source success story. take care, Gerd