From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=N4cb/GDW; spf=pass (domain: apple.com, ip: 17.151.62.67, mailfrom: afish@apple.com) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) by groups.io with SMTP; Wed, 05 Jun 2019 20:39:08 -0700 Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x563b0xu025091; Wed, 5 Jun 2019 20:39:08 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=PGrNjcugS67lOasor5aZ2ao5FfzQ/vbFJwhJQsSzadQ=; b=N4cb/GDWspCiduyJoLT58QtncSyK6haAMf+lx3kY3bMo8WpzFLgdSHQf42g1AI8JU/JB V9+kk38nGwfIEpbXLwERJ4D6gaWQazv3s0GKscq7BLLeQ7If7woMmlBC+DvDvLZdZYwq vxsLV0P/zRawgu1PtL85ANGe973+ETqcYznD/oYSq2NP/SK9rrO5WnaFKq8OoBZrLoui e4e19vsXLUYjJeJlw45UL+s4nAoQxfAnOs7NGkMSGfxsCnbM1VkzbLK4RwBqpiuO019E 8Pl213RCXZ0cirTTaUKLyKNyfH+4wlDUEc4UAY6wGT1WQaAN1OHR+vmntgTr8JbBIHiw Qw== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2sunydd29d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 05 Jun 2019 20:39:08 -0700 MIME-version: 1.0 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PSN0056FRH3RZ60@ma1-mtap-s02.corp.apple.com>; Wed, 05 Jun 2019 20:39:03 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PSN00F00QW1UZ00@nwk-mmpp-sz09.apple.com>; Wed, 05 Jun 2019 20:39:03 -0700 (PDT) X-Va-A: X-Va-T-CD: 112049e6de65b5a0f65d6cd65adaffe8 X-Va-E-CD: ac8228cf159adbb438adf1a2b8ce340d X-Va-R-CD: 8467635094ff22dc409490f5a1e66906 X-Va-CD: 0 X-Va-ID: 435b6c2f-b861-4960-b4a2-280f652ff940 X-V-A: X-V-T-CD: 112049e6de65b5a0f65d6cd65adaffe8 X-V-E-CD: ac8228cf159adbb438adf1a2b8ce340d X-V-R-CD: 8467635094ff22dc409490f5a1e66906 X-V-CD: 0 X-V-ID: f4d59fd6-c37c-4766-be40-8c1bf5b0b34f X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-06-06_03:,, signatures=0 Received: from [17.235.48.186] (unknown [17.235.48.186]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PSN000S1RH17W00@nwk-mmpp-sz09.apple.com>; Wed, 05 Jun 2019 20:39:02 -0700 (PDT) Sender: afish@apple.com From: "Andrew Fish" Message-id: <9CF43F28-86CB-4C2E-8A3F-DD110C6E8D5F@apple.com> Subject: Re: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix CLANG38 IA32 build problem Date: Wed, 05 Jun 2019 20:38:31 -0700 In-reply-to: Cc: "Gao, Liming" , "Bi, Dandan" , "Wang, Jian J" To: devel@edk2.groups.io, xiaoyux.lu@intel.com References: <1559712295-891-1-git-send-email-xiaoyux.lu@intel.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E46C045@SHSMSX104.ccr.corp.intel.com> X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-06-06_03:,, signatures=0 Content-type: multipart/alternative; boundary="Boundary_(ID_0NqL5MzDz3CrL0hovzBWbw)" --Boundary_(ID_0NqL5MzDz3CrL0hovzBWbw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > On Jun 4, 2019, at 11:33 PM, Xiaoyu Lu wrote: > > Hi Liming, > >> -----Original Message----- >> From: Gao, Liming >> Sent: Wednesday, June 5, 2019 1:57 PM >> To: devel@edk2.groups.io ; Lu, XiaoyuX > >> Cc: Bi, Dandan >; Wang, Jian J > >> Subject: RE: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix >> CLANG38 IA32 build problem >> >> Xiaoyu: >> >>> -----Original Message----- >>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of >>> Xiaoyu Lu >>> Sent: Wednesday, June 05, 2019 1:25 PM >>> To: devel@edk2.groups.io >>> Cc: Lu, XiaoyuX ; Bi, Dandan >> ; >>> Wang, Jian J >>> Subject: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix CLANG38 >>> IA32 build problem >>> >>> When use clang-3.8 to build the NetworkPkg, compiler optimization >>> may use memcpy for memory copy. For example: >>> >>> CryptoPkg/Library/OpensslLib/openssl/ssl/ssl_rsa.c:918: undefined >>> reference to `memcpy'` >>> >>> Compiler optimization is sophisticated, but we can work around it >>> use __attribute__((__used__)) to informs the compiler that symbol >>> should be retained in the object file, even if it may be >>> unreferenced. >>> >>> Cc: Jian J Wang >>> Cc: Dandan Bi >>> Signed-off-by: Xiaoyu Lu >>> --- >>> CryptoPkg/Library/IntrinsicLib/CopyMem.c | 13 +++++++++++++ >>> 1 file changed, 13 insertions(+) >>> >>> diff --git a/CryptoPkg/Library/IntrinsicLib/CopyMem.c >>> b/CryptoPkg/Library/IntrinsicLib/CopyMem.c >>> index e29b4918d200..7faf5a34d8c1 100644 >>> --- a/CryptoPkg/Library/IntrinsicLib/CopyMem.c >>> +++ b/CryptoPkg/Library/IntrinsicLib/CopyMem.c >>> @@ -10,8 +10,21 @@ SPDX-License-Identifier: BSD-2-Clause-Patent >>> #include >>> #include >>> >>> +#if defined(__clang__) && !defined(__APPLE__) >> >> So, this change is only for CLANG tool chain. >> >>> + >>> +/* Copies bytes between buffers */ >>> +static __attribute__((__used__)) >> >> What purpose for static? >> > > Because I want __memcpy only use in this file scope. > >>> +void * __memcpy (void *dest, const void *src, unsigned int count) >>> +{ >>> + return CopyMem (dest, src, (UINTN)count); >>> +} >>> +__attribute__((__alias__("__memcpy"))) >>> +void * memcpy (void *dest, const void *src, unsigned int count); >> >> __memcpy is IA32 Intrinsic API, memcpy is X64 Intrinsic API, right? >> > > __memcpy isn't IA32 Intrinsic API, only memcpy is intrinsic API for both IA32 and X64. > > The reason I alias memcpy and use __attribute__((__used__)) is let compiler retain symbol in object file, > So it can link correct. > > Is this correct? > I think this is a bug in clang that requires the __used__, we hit something like this with Xcode too. If the compiler emits the intrinsic it should tell the linker and some how that was getting missed. Thus the __used__ is a work around. Thanks, Andrew Fish >> Thanks >> Liming > >>> + >>> +#else >>> /* Copies bytes between buffers */ >>> void * memcpy (void *dest, const void *src, unsigned int count) >>> { >>> return CopyMem (dest, src, (UINTN)count); >>> } >>> +#endif >>> -- >>> 2.7.4 >>> >>> >>> > > > --Boundary_(ID_0NqL5MzDz3CrL0hovzBWbw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
On Jun 4,= 2019, at 11:33 PM, Xiaoyu Lu <xiaoyux.lu@intel.com> wrote:

Hi Liming,

-----Original Message-----
From: Gao, Liming
Sent: Wednesday, June 5, 2019 1:57 PM
To: devel@edk2.groups.io; Lu, XiaoyuX <xiaoyux.lu@intel.com>
Cc: Bi, Dandan <dan= dan.bi@intel.com>; Wang, Jian J <jian.j.wang@intel.com>
Subject: RE= : [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix
CLA= NG38 IA32 build problem

Xiaoyu:
=
-----Original Message--= ---
From: = devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
Xiaoyu Lu
Sent: Wednesday, June 05, 2019 1:25 PM
To: devel@edk2.groups.io
Cc: Lu, XiaoyuX <xiaoyux.lu@intel.com>; Bi, Dandan
= <dandan.bi@intel.com>;
Wang, Jian J <= ;jian.j.wang@intel.com<= /a>>
Subject: [edk2-devel] [PATCH v1 1/1] CryptoPkg/Intrin= sicLib: Fix CLANG38
IA32 build problem

When use clang-3.8 to build the NetworkPkg, compiler optimizationmay use memcpy for memory copy. For example:

CryptoPkg/Library/OpensslLib/openssl/ssl/ssl_rsa.c:918: undefine= d
reference to `memcpy'`

Compile= r optimization is sophisticated, but we can work around it
us= e __attribute__((__used__)) to informs the compiler that symbol
should be retained in the object file, even if it may be
u= nreferenced.

Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Signed-off-by: Xiaoyu Lu <xiaoyux.lu@intel.com>= ;
---
CryptoPkg/Library/IntrinsicLib/CopyMem.c = | 13 +++++++++++++
1 file changed, 13 insertions(+)

diff --git a/CryptoPkg/Library/IntrinsicLib/CopyMem.c=
b/CryptoPkg/Library/IntrinsicLib/CopyMem.c
ind= ex e29b4918d200..7faf5a34d8c1 100644
--- a/CryptoPkg/Library/= IntrinsicLib/CopyMem.c
+++ b/CryptoPkg/Library/IntrinsicLib/C= opyMem.c
@@ -10,8 +10,21 @@ SPDX-License-Identifier: BSD-2-Cl= ause-Patent
#include <Base.h>
#include &l= t;Library/BaseMemoryLib.h>

+#if defined(__c= lang__) && !defined(__APPLE__)

So, this change is only for CLANG tool chain.

+
+/* Copies byte= s between buffers */
+static __attribute__((__used__))

What purpose for static?
=

B= ecause I want __memcpy only use in this file scope.

+void * __memcpy (void *dest, c= onst void *src, unsigned int count)
+{
+  = return CopyMem (dest, src, (UINTN)count);
+}
+_= _attribute__((__alias__("__memcpy")))
+void * memcpy (void *d= est, const void *src, unsigned int count);

__memcpy is IA32 Intrinsic API, memcpy is X64 Intrinsic API, righ= t?


__memcpy isn't IA32 Intrinsic API, only memcpy is intrinsic= API for both IA32 and X64.
The reason I alias memcpy and u= se __attribute__((__used__)) is let compiler retain symbol in object file,<= /span>
So it can link correct.=

Is this correct?


I think this is a bug in clang that requires the __use= d__, we hit something like this with Xcode too. If the compiler emits the i= ntrinsic it should tell the linker and some how that was getting missed. Th= us the __used__ is a work around. 

Thanks,

Andrew Fish

= Thanks
Liming

+
+#else
/* Copies bytes between buffers */void * memcpy (void *dest, const void *src, unsigned int count)=
{
 return CopyMem (dest, src, (UINTN)coun= t);
}
+#endif
--
2.= 7.4






--Boundary_(ID_0NqL5MzDz3CrL0hovzBWbw)--