| Message ID | 20161209135417.15294bf2@squid.athome |
|---|---|
| State | New |
| Headers | show |
On Dec 9 13:54, Julian Brown wrote: > Hi, > > I noticed that memcpy-armv7m.S makes assumptions about little-endian > byte ordering that cause it to get copies with certain sizes/alignments > wrong in big-endian mode. We hit this with a "generic profile" ARMv7 > big-endian multilib, but I guess anyone trying to run an M-profile chip > in big-endian mode (if such things exist) could hit the same problem. > > I've tested this with (caveat, somewhat experimental!) QEMU patches: > > http://lists.nongnu.org/archive/html/qemu-devel/2016-12/msg00972.html > > running under the GCC testsuite with an ARMv7 big-endian multilib, and > results show a positive delta for about 15 tests (e.g. > gcc.c-torture/execute/memcpy-2.c, gcc.c-torture/execute/pr65369.c). > > OK to apply? Applied. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat
commit 45cd47548c95b13eed1eb0121ee15ca63df1b466
Author: Julian Brown <julian@codesourcery.com>
Date: Thu Dec 8 09:56:51 2016 -0800
Big-endian armv7m memcpy fix.
In the case of memcpy-armv7m.S being built for a big-endian multilib
(including armv7 without a specific profile), realignment code made
assumptions about the byte ordering being little-endian.
diff --git a/newlib/libc/machine/arm/memcpy-armv7m.S b/newlib/libc/machine/arm/memcpy-armv7m.S
index 8a70c7d..c8bff36 100644
--- a/newlib/libc/machine/arm/memcpy-armv7m.S
+++ b/newlib/libc/machine/arm/memcpy-armv7m.S
@@ -265,9 +265,17 @@ memcpy:
.macro mis_src_copy shift
1:
+#ifdef __ARM_BIG_ENDIAN
+ lsls r4, r4, \shift
+#else
lsrs r4, r4, \shift
+#endif
ldr r3, [r1], #4
+#ifdef __ARM_BIG_ENDIAN
+ lsrs r5, r3, 32-\shift
+#else
lsls r5, r3, 32-\shift
+#endif
orr r4, r4, r5
str r4, [r0], #4
mov r4, r3
Hi, I noticed that memcpy-armv7m.S makes assumptions about little-endian byte ordering that cause it to get copies with certain sizes/alignments wrong in big-endian mode. We hit this with a "generic profile" ARMv7 big-endian multilib, but I guess anyone trying to run an M-profile chip in big-endian mode (if such things exist) could hit the same problem. I've tested this with (caveat, somewhat experimental!) QEMU patches: http://lists.nongnu.org/archive/html/qemu-devel/2016-12/msg00972.html running under the GCC testsuite with an ARMv7 big-endian multilib, and results show a positive delta for about 15 tests (e.g. gcc.c-torture/execute/memcpy-2.c, gcc.c-torture/execute/pr65369.c). OK to apply? Thanks, Julian ChangeLog * libc/machine/arm/memcpy-armv7m.S (mis_src_copy): Handle big-endian mode.