From: "Liming Gao" <liming.gao@intel.com>
To: "afish@apple.com" <afish@apple.com>,
"devel@edk2.groups.io" <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
Date: Thu, 6 Jun 2019 03:50:51 +0000 [thread overview]
Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14E46C929@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <9CF43F28-86CB-4C2E-8A3F-DD110C6E8D5F@apple.com>
[-- Attachment #1: Type: text/plain, Size: 3944 bytes --]
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>
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: Fix CLANG38 IA32 build problem
On Jun 4, 2019, at 11:33 PM, Xiaoyu Lu <xiaoyux.lu@intel.com<mailto: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<mailto:devel@edk2.groups.io>; Lu, XiaoyuX <xiaoyux.lu@intel.com<mailto:xiaoyux.lu@intel.com>>
Cc: Bi, Dandan <dandan.bi@intel.com<mailto:dandan.bi@intel.com>>; Wang, Jian J <jian.j.wang@intel.com<mailto: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> [mailto:devel@edk2.groups.io] On Behalf Of
Xiaoyu Lu
Sent: Wednesday, June 05, 2019 1:25 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Cc: Lu, XiaoyuX <xiaoyux.lu@intel.com<mailto:xiaoyux.lu@intel.com>>; Bi, Dandan
<dandan.bi@intel.com<mailto:dandan.bi@intel.com>>;
Wang, Jian J <jian.j.wang@intel.com<mailto: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@intel.com<mailto:jian.j.wang@intel.com>>
Cc: Dandan Bi <dandan.bi@intel.com<mailto:dandan.bi@intel.com>>
Signed-off-by: Xiaoyu Lu <xiaoyux.lu@intel.com<mailto: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
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 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.
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
[-- Attachment #2: Type: text/html, Size: 12668 bytes --]
prev parent reply other threads:[~2019-06-06 3:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-05 5:24 [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix CLANG38 IA32 build problem Xiaoyu Lu
2019-06-05 5:56 ` [edk2-devel] " Liming Gao
2019-06-05 6:33 ` Xiaoyu Lu
2019-06-05 7:28 ` Liming Gao
2019-06-05 7:34 ` Xiaoyu Lu
2019-06-05 7:37 ` Liming Gao
2019-06-05 7:50 ` Xiaoyu Lu
2019-06-05 7:56 ` Liming Gao
[not found] ` <15A53E5388BBDBAF.17041@groups.io>
2019-06-06 3:23 ` Liming Gao
2019-06-06 3:38 ` Andrew Fish
2019-06-06 3:50 ` Liming Gao [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A89E2EF3DFEDB4C8BFDE51014F606A14E46C929@SHSMSX104.ccr.corp.intel.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox