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.129.124])
 by mx.groups.io with SMTP id smtpd.web11.46539.1643709016460689300
 for <devel@edk2.groups.io>;
 Tue, 01 Feb 2022 01:50:16 -0800
Authentication-Results: mx.groups.io;
 dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=dstkv9pt;
 spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: kraxel@redhat.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1643709015;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=jolyebu8LvBRhPen/NljNj1FO66ttcMYTcVNH5WYF9o=;
	b=dstkv9ptp86Hjel/peVj4PRAagycONzPCH/8mEuEwVWJcPQPFvXv14HduQKRM6sh1QfBEh
	6sBa31HtwQwzc5HHSM+cbvfdHuWxzdbWNa/HQGJF3CFbFFTUvDsFZJtpIpyz1zaoI2i0dd
	9+N+q8/8bHCO224sjmSdnCUo5SDh3ns=
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-647-37-UgQKDOG2U3X_biUqS4g-1; Tue, 01 Feb 2022 04:50:12 -0500
X-MC-Unique: 37-UgQKDOG2U3X_biUqS4g-1
Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 699F010A4E8B;
	Tue,  1 Feb 2022 09:50:11 +0000 (UTC)
Received: from sirius.home.kraxel.org (unknown [10.39.193.47])
	by smtp.corp.redhat.com (Postfix) with ESMTPS id 34E27106F757;
	Tue,  1 Feb 2022 09:50:11 +0000 (UTC)
Received: by sirius.home.kraxel.org (Postfix, from userid 1000)
	id 7B8B21800632; Tue,  1 Feb 2022 10:50:06 +0100 (CET)
Date: Tue, 1 Feb 2022 10:50:06 +0100
From: "Gerd Hoffmann" <kraxel@redhat.com>
To: devel@edk2.groups.io, pedro.falcato@gmail.com
Subject: Re: [edk2-devel] [PATCH 00/24] CryptoPkg/openssl: update openssl submodule to v3.0
Message-ID: <20220201095006.q6u6m6xmzzz5os5o@sirius.home.kraxel.org>
References: <20220128140723.isljt6lz6the7k5y@sirius.home.kraxel.org>
 <CAKbZUD2ZaR7gqRhdhuvwWQnyXqY8BYDGCHM3xjL=UMc-fX1dHQ@mail.gmail.com>
MIME-Version: 1.0
In-Reply-To: <CAKbZUD2ZaR7gqRhdhuvwWQnyXqY8BYDGCHM3xjL=UMc-fX1dHQ@mail.gmail.com>
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22
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

On Fri, Jan 28, 2022 at 04:00:26PM +0000, Pedro Falcato wrote:
> Also, quick note: I've seen linking blowing up because the ABIs being used
> in the bare metal code and in libgcc were different; this was in riscv64. I
> know x86 doesn't do such checks but a few others do, including RISCV (they
> tag object files with the ABI). This makes libgcc unusable in such
> architectures.

Same on arm, object files seem to be tagged with the floating point abi
used (even in case the object files doesn't actually use floating point
instructions) and the linker throws errors in case there is a mismatch.

> If we want to provide intrinsics, then possibly shipping our own
> compiler-rt would be the only solid option.

Yes, I suspect that'll work better than trying to use the
compiler-shipped intrinsics.

But in any case we should have a single intrinsic library for
everybody to use.

take care,
  Gerd