From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web09.795.1605297732077399811 for ; Fri, 13 Nov 2020 12:02:12 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=QNKDheiJ; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605297731; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Xaa+LlD4pAPRcWGM0bcdGm0f3w4mO8HxHWTy8ULsH1g=; b=QNKDheiJR9tnKKWGl/oleN2UbRKPWLHvQ/FPgH2SOInhIEsOUjGfDJqJOxn0ks5Pcv4d9l lyimrgw06b5Bk3LLQRWvz7R1nG5MBP08KJYL+SJFdzm6s1CRwsJmIwrekxrGQF0KClGCkG bFddx7W+lNKFaF5GKjP5RHG9S2e4aVY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-185-0AIiFP3EP1iMrVPYEnE2cA-1; Fri, 13 Nov 2020 15:02:07 -0500 X-MC-Unique: 0AIiFP3EP1iMrVPYEnE2cA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 99CDB8030C1; Fri, 13 Nov 2020 20:02:05 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-113.ams2.redhat.com [10.36.112.113]) by smtp.corp.redhat.com (Postfix) with ESMTP id DF1DA6EF52; Fri, 13 Nov 2020 20:02:03 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v5 0/2] CryptoPkg/OpensslLib: Add native instruction support for X64 To: Ard Biesheuvel , "Zurcher, Christopher J" , "devel@edk2.groups.io" , "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: "Laszlo Ersek" Message-ID: <74cc08cf-e1f8-fa19-3ca9-a87cf05923cd@redhat.com> Date: Fri, 13 Nov 2020 21:02:03 +0100 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 11/13/20 08:35, Ard Biesheuvel wrote: > 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? My guess is that the GAS source that OpenSSL generates for the crypto primitives in question is simply broken -- the GAS source probably includes multiple external definitions (not just declarations) for the same objects. If that's the case, then it's a genuine bug in OpenSSL. Thanks Laszlo