linux-kernel - [PATCH 1/4] perf/x86-64: make "default" memcpy() selection actually use glibc's implementation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <4F16D6FD020000780006D72F@nat28.tlf.novell.com>
Date:	Wed, 18 Jan 2012 13:28:13 +0000
From:	"Jan Beulich" <JBeulich@...e.com>
To:	<a.p.zijlstra@...llo.nl>, <mingo@...e.hu>,
	<acme@...stprotocols.net>, <paulus@...ba.org>
Cc:	<linux-kernel@...r.kernel.org>
Subject: [PATCH 1/4] perf/x86-64: make "default" memcpy() selection
 actually use glibc's implementation

Since arch/x86/lib/memcpy_64.S implements not only __memcpy, but also
memcpy, without further precautions this function will get chose by the
static linker for resolving all references, and hence the "default"
measurement didn't really measure anything else than the
"x86-64-unrolled" one.

Fix this by renaming (through the pre-processor) the conflicting
symbol.

On my Westmere system, the glibc variant turns out to require about 4%
less instructions, but 15% more cycles for the default 1Mb block size
measured.

Signed-off-by: Jan Beulich <jbeulich@...e.com>

--- a/tools/perf/bench/mem-memcpy-x86-64-asm.S
+++ b/tools/perf/bench/mem-memcpy-x86-64-asm.S
@@ -1,2 +1,2 @@
-
+#define memcpy MEMCPY /* don't hide glibc's memcpy() */
 #include "../../../arch/x86/lib/memcpy_64.S"

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/