From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 134.134.136.100, mailfrom: liming.gao@intel.com) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by groups.io with SMTP; Wed, 05 Jun 2019 20:50:56 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jun 2019 20:50:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,557,1549958400"; d="scan'208,217";a="182169155" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga002.fm.intel.com with ESMTP; 05 Jun 2019 20:50:54 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 5 Jun 2019 20:50:54 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.137]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.6]) with mapi id 14.03.0415.000; Thu, 6 Jun 2019 11:50:52 +0800 From: "Liming Gao" To: "afish@apple.com" , "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 Thread-Topic: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix CLANG38 IA32 build problem Thread-Index: AQHVG19PQyx+GkN+oUK1k7ap2DC1gqaMjrsg//+FpgCAAWFjgIAAiJZQ Date: Thu, 6 Jun 2019 03:50:51 +0000 Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14E46C929@SHSMSX104.ccr.corp.intel.com> References: <1559712295-891-1-git-send-email-xiaoyux.lu@intel.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E46C045@SHSMSX104.ccr.corp.intel.com> <9CF43F28-86CB-4C2E-8A3F-DD110C6E8D5F@apple.com> In-Reply-To: <9CF43F28-86CB-4C2E-8A3F-DD110C6E8D5F@apple.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiM2ZjOWE4ZDQtYTY3Yi00YTAxLTljNmQtOTU0Yzg3MDZmOTk0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiTDhvTE5vTm1nVklXZSsxMEgyZDNYVHRxUW9tZHJVT3BMTVdFZ0FMU1FZeHZoWVROcW5QRE9penNFV2hTeTZFRiJ9 dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: liming.gao@intel.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_4A89E2EF3DFEDB4C8BFDE51014F606A14E46C929SHSMSX104ccrcor_" --_000_4A89E2EF3DFEDB4C8BFDE51014F606A14E46C929SHSMSX104ccrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fish: From: afish@apple.com [mailto:afish@apple.com] Sent: Thursday, June 6, 2019 11:39 AM To: devel@edk2.groups.io; Lu, XiaoyuX Cc: Gao, Liming ; Bi, Dandan ; = Wang, Jian J Subject: Re: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix CLANG= 38 IA32 build problem 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, Ji= an 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, D= andan >; 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 I= A32 and X64. The reason I alias memcpy and use __attribute__((__used__)) is let compile= r 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 somethin= g like this with Xcode too. If the compiler emits the intrinsic it should t= ell the linker and some how that was getting missed. Thus the __used__ is a= work around. OK. It is for CLANG 3.8. I will check whether the latest CLANG8.0 fixes it= . 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 --_000_4A89E2EF3DFEDB4C8BFDE51014F606A14E46C929SHSMSX104ccrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Fish:

 

From: afish@apple.com [mailto:afish@apple= .com]
Sent: Thursday, June 6, 2019 11:39 AM
To: devel@edk2.groups.io; Lu, XiaoyuX <xiaoyux.lu@intel.com><= br> Cc: Gao, Liming <liming.gao@intel.com>; Bi, Dandan <dandan= .bi@intel.com>; Wang, Jian J <jian.j.wang@intel.com>
Subject: Re: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fi= x CLANG38 IA32 build problem

 

 



On Jun 4, 2019, at 11:33 PM, X= iaoyu 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 <dandan.bi@intel.= com>; Wang, Jian J <jian= .j.wang@intel.com>
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 B= ehalf Of
Xiaoyu Lu
Sent: Wednesday, June 05, 2019 1:25 PM
To: devel@edk2.groups.io
Cc: Lu, XiaoyuX <xiaoyux.lu@int= el.com>; Bi, Dandan

<dandan.bi@intel.com>;

Wang, Jian J <jian.j.wang@intel.com>
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 <jian.j.wang@i= ntel.com>
Cc: Dandan Bi <dandan.bi@intel.c= om>
Signed-off-by: Xiaoyu Lu <xiaoy= ux.lu@intel.com>
---
CryptoPkg/Library/IntrinsicLib/CopyMem.c | 13 +++++= 3;+++++++
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 <Base.h>
#include <Library/BaseMemoryLib.h>

+#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 I= A32 and X64.

The reason I alias memcpy and use __attribute__((__used__)) is let compile= r 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 tha= t was getting missed. Thus the __used__ is a work around. 

&= nbsp;

OK. It is for CLANG 3= .8. I will check whether the latest CLANG8.0 fixes it.

 

Thanks,

 

Andrew Fish<= /p>



Thanks
Liming



= 3;
+#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




 

--_000_4A89E2EF3DFEDB4C8BFDE51014F606A14E46C929SHSMSX104ccrcor_--