| Message ID | 95923e664fc9426c9c121efeaa69268c@huawei.com |
|---|---|
| State | New |
| Headers | show |
| Series | [v2] memcpy: use bhs/bls instead of bge/blt [BZ #25620] | expand |
On Mon, 13 Apr 2020, zhuyan (M) wrote: > In ARMv7, the memcpy() implementation allows for program execution to > continue in scenarios where a segmentation fault or crash should have > occurred. The dangers occur in that subsequent execution and iterations > of this code will be executed with this corrupted data. > > Such as, we use 'memcpy' copy 0x80000000 byte to buffer(The buffer size > is 100 bytes), it didn't crash. This patch includes an architecture-specific test, specific to memcpy. My understanding of Wilco's request in bug 25620 was for an architecture-independent test or tests, covering all string functions with such large arguments, so we can ensure we're consistent across architectures. To quote comment 16, "Still we should have a new test that checks every string function which has a size_t input, using a positive test if the huge mmap succeeds and a negative test checking for a crash. That should flush out any other cases across all targets.". Even if you just add a test of memcpy and leave testing other string functions for later, I think it ought to be an architecture-independent test. Note 1: we can't effectively test for this issue on 64-bit systems, because a 2^63 byte allocation isn't generally practical (the virtual address space may not actually support using all 64 bits) and looping over the whole of such an allocation would take an infeasible amount of time. Note 2: to avoid problems with allocation failure when writing to the whole of such a large allocation on a 32-bit system that doesn't actually have 2 GB of memory available, see support/blob_repeat.c that provides helper functions, for use in testcases, that repeat mappings of a smaller region of memory over a larger part of the address space. > +#define TEST_FUNCTION do_test () > +#include "../test-skeleton.c" test-skeleton.c is the older way of writing tests. New tests should use support/test-driver.c, see support/README-testing.c.
* Joseph Myers: > On Mon, 13 Apr 2020, zhuyan (M) wrote: > >> In ARMv7, the memcpy() implementation allows for program execution to >> continue in scenarios where a segmentation fault or crash should have >> occurred. The dangers occur in that subsequent execution and iterations >> of this code will be executed with this corrupted data. >> >> Such as, we use 'memcpy' copy 0x80000000 byte to buffer(The buffer size >> is 100 bytes), it didn't crash. > > This patch includes an architecture-specific test, specific to memcpy. > My understanding of Wilco's request in bug 25620 was for an > architecture-independent test or tests, covering all string functions with > such large arguments, so we can ensure we're consistent across > architectures. Sure, that would be great, but can we make this independent of this fix, please?
On Tue, 21 Apr 2020, Florian Weimer wrote: > * Joseph Myers: > > > On Mon, 13 Apr 2020, zhuyan (M) wrote: > > > >> In ARMv7, the memcpy() implementation allows for program execution to > >> continue in scenarios where a segmentation fault or crash should have > >> occurred. The dangers occur in that subsequent execution and iterations > >> of this code will be executed with this corrupted data. > >> > >> Such as, we use 'memcpy' copy 0x80000000 byte to buffer(The buffer size > >> is 100 bytes), it didn't crash. > > > > This patch includes an architecture-specific test, specific to memcpy. > > My understanding of Wilco's request in bug 25620 was for an > > architecture-independent test or tests, covering all string functions with > > such large arguments, so we can ensure we're consistent across > > architectures. > > Sure, that would be great, but can we make this independent of this > fix, please? I think the minimum for this fix should be an architecture-independent test for memcpy (but not other string functions, and not necessarily testing all IFUNC variants of memcpy).
* Joseph Myers: > On Tue, 21 Apr 2020, Florian Weimer wrote: > >> * Joseph Myers: >> >> > On Mon, 13 Apr 2020, zhuyan (M) wrote: >> > >> >> In ARMv7, the memcpy() implementation allows for program execution to >> >> continue in scenarios where a segmentation fault or crash should have >> >> occurred. The dangers occur in that subsequent execution and iterations >> >> of this code will be executed with this corrupted data. >> >> >> >> Such as, we use 'memcpy' copy 0x80000000 byte to buffer(The buffer size >> >> is 100 bytes), it didn't crash. >> > >> > This patch includes an architecture-specific test, specific to memcpy. >> > My understanding of Wilco's request in bug 25620 was for an >> > architecture-independent test or tests, covering all string functions with >> > such large arguments, so we can ensure we're consistent across >> > architectures. >> >> Sure, that would be great, but can we make this independent of this >> fix, please? > > I think the minimum for this fix should be an architecture-independent > test for memcpy (but not other string functions, and not necessarily > testing all IFUNC variants of memcpy). Fair enough. I'll try to write one using the RAM compression feature I added. But I can't get a 32-bit Arm machine from the labs at work right now, and it may be a while until I get a device delivered, so it will be at least a few days more until I have a test that's been confirmed to reproduce the bug.
* zhuyan: > - blt .Ltail63aligned > + bls .Ltail63aligned Is bls really the unsigned variant of blt? Why not blo?
* Joseph Myers: > On Tue, 21 Apr 2020, Florian Weimer wrote: > >> * Joseph Myers: >> >> > On Mon, 13 Apr 2020, zhuyan (M) wrote: >> > >> >> In ARMv7, the memcpy() implementation allows for program execution to >> >> continue in scenarios where a segmentation fault or crash should have >> >> occurred. The dangers occur in that subsequent execution and iterations >> >> of this code will be executed with this corrupted data. >> >> >> >> Such as, we use 'memcpy' copy 0x80000000 byte to buffer(The buffer size >> >> is 100 bytes), it didn't crash. >> > >> > This patch includes an architecture-specific test, specific to memcpy. >> > My understanding of Wilco's request in bug 25620 was for an >> > architecture-independent test or tests, covering all string functions with >> > such large arguments, so we can ensure we're consistent across >> > architectures. >> >> Sure, that would be great, but can we make this independent of this >> fix, please? > > I think the minimum for this fix should be an architecture-independent > test for memcpy (but not other string functions, and not necessarily > testing all IFUNC variants of memcpy). I think it should be for memmove, because memmove is actually defined in this case. The test below passes on i686-linux-gnu and x86_64-linux-gnu. I still see a failure with the memcpy implementation from sysdeps/arm/armv7/multiarch/memcpy_impl.S: info: testing memmove tst-memmove-overflow.c:134: error: blob comparison failed blob length: 128 bytes left (evaluated from expected_start): "O\036m<\vZ)xG\027f5\004S\"q@\017_.}L\033j9\bW\'vE\024c2\001P\037o>\r\\+zI\030g6\006U$sB\021`/~N\035l;\nY(wF\026e4\003R!p?\016^-|K\032i8\aV%uD\023b1\000O\036m=\f[*yH\027f5\005T#rA\020_.}M\034k:\tX\'vE\025d3\002Q o>\r" 4F 1E 6D 3C 0B 5A 29 78 47 17 66 35 04 53 22 71 40 0F 5F 2E 7D 4C 1B 6A 39 08 57 27 76 45 14 63 32 01 50 1F 6F 3E 0D 5C 2B 7A 49 18 67 36 06 55 24 73 42 11 60 2F 7E 4E 1D 6C 3B 0A 59 28 77 46 16 65 34 03 52 21 70 3F 0E 5E 2D 7C 4B 1A 69 38 07 56 25 75 44 13 62 31 00 4F 1E 6D 3D 0C 5B 2A 79 48 17 66 35 05 54 23 72 41 10 5F 2E 7D 4D 1C 6B 3A 09 58 27 76 45 15 64 33 02 51 20 6F 3E 0D right (evaluated from start): "O\036m<\vZ)xG\027f5\004S\"q@\017_.}L\033j9\bW\'vE\024c2\001P\037o>\r\\+zI\030g6\006U$sB\021`/~N\035l;\nY(wwF\026e4\003R!p?\016^-|K\032i8\aV%uD\023b1\000O\036m=\f[*yH\027f5\005T#rA\020_.}M\034k:\tX\'vE\025d3\002Q o>" 4F 1E 6D 3C 0B 5A 29 78 47 17 66 35 04 53 22 71 40 0F 5F 2E 7D 4C 1B 6A 39 08 57 27 76 45 14 63 32 01 50 1F 6F 3E 0D 5C 2B 7A 49 18 67 36 06 55 24 73 42 11 60 2F 7E 4E 1D 6C 3B 0A 59 28 77 77 46 16 65 34 03 52 21 70 3F 0E 5E 2D 7C 4B 1A 69 38 07 56 25 75 44 13 62 31 00 4F 1E 6D 3D 0C 5B 2A 79 48 17 66 35 05 54 23 72 41 10 5F 2E 7D 4D 1C 6B 3A 09 58 27 76 45 15 64 33 02 51 20 6F 3E tst-memmove-overflow.c:137: error: blob comparison failed blob length: 128 bytes left (evaluated from expected_end): " o>\r\\+{J\031h7\006U$sC\022a0\177N\035l;\nZ)xG\026e4\003R\"q@\017^-|K\032j9\bW&uD\023b2\001P\037n=\f[*yI\030g6\005T#rA\021`/~M\034k:\tY(wF\025d3\002Q!p?\016],{J\031h8\aV%tC\022a0\000O\036m<\vZ)xH\027f5\004S\"q@\020_" 20 6F 3E 0D 5C 2B 7B 4A 19 68 37 06 55 24 73 43 12 61 30 7F 4E 1D 6C 3B 0A 5A 29 78 47 16 65 34 03 52 22 71 40 0F 5E 2D 7C 4B 1A 6A 39 08 57 26 75 44 13 62 32 01 50 1F 6E 3D 0C 5B 2A 79 49 18 67 36 05 54 23 72 41 11 60 2F 7E 4D 1C 6B 3A 09 59 28 77 46 15 64 33 02 51 21 70 3F 0E 5D 2C 7B 4A 19 68 38 07 56 25 74 43 12 61 30 00 4F 1E 6D 3C 0B 5A 29 78 48 17 66 35 04 53 22 71 40 10 5F right (evaluated from start + allocation_size - sizeof (expected_end) - 1): "Q o>\r\\+{J\031h7\006U$sC\022a0\177N\035l;\nZ)xG\026e4\003R\"q@\017^-|K\032j9\bW&uD\023b2\001P\037n=\f[*yI\030g6\005T#rA\021`/~M\034k:\tY(wF\025d3\002Q!p?\016],{J\031h8\aV%tC\022a0\000O\036m<\vZ)xH\027f5\004S\"q@\020" 51 20 6F 3E 0D 5C 2B 7B 4A 19 68 37 06 55 24 73 43 12 61 30 7F 4E 1D 6C 3B 0A 5A 29 78 47 16 65 34 03 52 22 71 40 0F 5E 2D 7C 4B 1A 6A 39 08 57 26 75 44 13 62 32 01 50 1F 6E 3D 0C 5B 2A 79 49 18 67 36 05 54 23 72 41 11 60 2F 7E 4D 1C 6B 3A 09 59 28 77 46 15 64 33 02 51 21 70 3F 0E 5D 2C 7B 4A 19 68 38 07 56 25 74 43 12 61 30 00 4F 1E 6D 3C 0B 5A 29 78 48 17 66 35 04 53 22 71 40 10 tst-memmove-overflow.c:139: numeric comparison failure left: 119 (0x77); from: start[i] right: 70 (0x46); from: expected_value (i + 1) […] Apparently, the copy stops after the first 62 bytes. Furthermore, the test exposes a similar bug in sysdeps/arm/memcpy.S: ENTRY(memcpy) […] subs r2, r2, #4 blt 8f So an early exit is taken. 8<------------------------------------------------------------------8< Subject: string: Add string/tst-memmove-overflow, a test case for bug 25620 ----- string/Makefile | 2 +- string/tst-memmove-overflow.c | 153 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 154 insertions(+), 1 deletion(-) diff --git a/string/Makefile b/string/Makefile index c46785f1a1..e1cca5516b 100644 --- a/string/Makefile +++ b/string/Makefile @@ -60,7 +60,7 @@ tests := tester inl-tester noinl-tester testcopy test-ffs \ bug-envz1 tst-strxfrm2 tst-endian tst-svc2 \ tst-strtok_r bug-strcoll2 tst-cmp tst-xbzero-opt \ test-endian-types test-endian-file-scope \ - test-endian-sign-conversion + test-endian-sign-conversion tst-memmove-overflow # This test allocates a lot of memory and can run for a long time. xtests = tst-strcoll-overflow diff --git a/string/tst-memmove-overflow.c b/string/tst-memmove-overflow.c new file mode 100644 index 0000000000..8e7a533266 --- /dev/null +++ b/string/tst-memmove-overflow.c @@ -0,0 +1,153 @@ +/* Test for signed comparision bug in memmove (bug 25620). + Copyright (C) 2020 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, see + <https://www.gnu.org/licenses/>. */ + +/* This test shifts a memory region which is a bit larger than 2 GiB + by one byte. In order to make it more likely that the memory + allocation succeeds on 32-bit systems, most of the allocation + consists of shared pages. Only a portion at the start and end of + the allocation are unshared, and contain a specific non-repeating + bit pattern. */ + +#include <array_length.h> +#include <libc-diag.h> +#include <stdint.h> +#include <string.h> +#include <support/blob_repeat.h> +#include <support/check.h> +#include <support/xunistd.h> +#include <sys/mman.h> +#include <unistd.h> + +#define TEST_MAIN +#define TEST_NAME "memmove" +#include "test-string.h" +#include <support/test-driver.h> + +IMPL (memmove, 1) + +/* The allocation is 2 GiB plus 8 MiB large. This should work with + all page sizes that occur in practice. */ +static const size_t allocation_size = (2U << 30) + (8U << 20); + +/* Size of the part of the allocation which is not shared, at the + start and the end of the overall allocation. 4 MiB. */ +static const size_t unshared_size = 4U << 20; + +/* Compute the expected byte at the given index. This is used to + produce a non-repeating pattern. */ +static inline unsigned char +expected_value (size_t index) +{ + uint32_t randomized = 0x9e3779b9 * index; /* Based on golden ratio. */ + return randomized >> 25; /* Result is in the range [0, 127]. */ +} + +static int +test_main (void) +{ + test_init (); + + FOR_EACH_IMPL (impl, 0) + { + printf ("info: testing %s\n", impl->name); + + /* Check that the allocation sizes are multiples of the page + size. */ + TEST_COMPARE (allocation_size % xsysconf (_SC_PAGESIZE), 0); + TEST_COMPARE (unshared_size % xsysconf (_SC_PAGESIZE), 0); + + /* The repeating pattern has the MSB set in all bytes. */ + unsigned char repeating_pattern[128]; + for (unsigned int i = 0; i < array_length (repeating_pattern); ++i) + repeating_pattern[i] = 0x80 | i; + + struct support_blob_repeat repeat + = support_blob_repeat_allocate (repeating_pattern, + sizeof (repeating_pattern), + (allocation_size + / sizeof (repeating_pattern))); + if (repeat.start == NULL) + FAIL_UNSUPPORTED ("repeated blob allocation failed: %m"); + TEST_COMPARE (repeat.size, allocation_size); + + /* Unshared the start and the end of the allocation. */ + unsigned char *start = repeat.start; + xmmap (start, unshared_size, + PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1); + xmmap (start + allocation_size - unshared_size, unshared_size, + PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1); + + /* Initialize the non-repeating pattern. */ + for (size_t i = 0; i < unshared_size; ++i) + start[i] = expected_value (i); + for (size_t i = allocation_size - unshared_size; i < allocation_size; + ++i) + start[i] = expected_value (i); + + /* Make sure that there was really no sharing. */ + asm volatile ("" ::: "memory"); + for (size_t i = 0; i < unshared_size; ++i) + TEST_COMPARE (start[i], expected_value (i)); + for (size_t i = allocation_size - unshared_size; i < allocation_size; + ++i) + TEST_COMPARE (start[i], expected_value (i)); + + /* Used for a nicer error diagnostic using + TEST_COMPARE_BLOB. */ + unsigned char expected_start[128]; + memcpy (expected_start, start + 1, sizeof (expected_start)); + unsigned char expected_end[128]; + memcpy (expected_end, + start + allocation_size - sizeof (expected_end), + sizeof (expected_end)); + + /* Move the entire allocation forward by one byte. */ + DIAG_PUSH_NEEDS_COMMENT; +#if __GNUC_PREREQ (8, 0) + /* GCC 8 warns about string function argument overflows. */ + DIAG_IGNORE_NEEDS_COMMENT (8, "-Warray-bounds"); + DIAG_IGNORE_NEEDS_COMMENT (8, "-Wstringop-overflow"); +#endif + memmove (start, start + 1, allocation_size - 1); + DIAG_POP_NEEDS_COMMENT; + + /* Check that the unshared of the memory region have been + shifted as expected. The TEST_COMPARE_BLOB checks are + redundant, but produce nicer diagnostics. */ + asm volatile ("" ::: "memory"); + TEST_COMPARE_BLOB (expected_start, sizeof (expected_start), + start, sizeof (expected_start)); + TEST_COMPARE_BLOB (expected_end, sizeof (expected_end), + start + allocation_size - sizeof (expected_end) - 1, + sizeof (expected_end)); + for (size_t i = 0; i < unshared_size - 1; ++i) + TEST_COMPARE (start[i], expected_value (i + 1)); + /* The gap between the start and the end has shared mappings at + unspecified boundaries, so do not check the expected values + here. */ + for (size_t i = allocation_size - unshared_size; i < allocation_size - 1; + ++i) + TEST_COMPARE (start[i], expected_value (i + 1)); + + support_blob_repeat_free (&repeat); + } + + return 0; +} + +#include <support/test-driver.c>
diff --git a/sysdeps/arm/Makefile b/sysdeps/arm/Makefile index ad2042b93a..7c1f19e225 100644 --- a/sysdeps/arm/Makefile +++ b/sysdeps/arm/Makefile @@ -19,21 +19,25 @@ lib-noranlib: $(objpfx)libgcc-stubs.a ifeq ($(build-shared),yes) ifeq ($(have-arm-tls-desc),yes) -tests += tst-armtlsdescloc tst-armtlsdescextnow tst-armtlsdescextlazy +tests += tst-armtlsdescloc tst-armtlsdescextnow tst-armtlsdescextlazy +tst-armv7memcpybign modules-names += tst-armtlsdesclocmod modules-names += tst-armtlsdescextlazymod tst-armtlsdescextnowmod +modeles-names += tst-armv7memcpybignmod CPPFLAGS-tst-armtlsdescextnowmod.c += -Dstatic= CPPFLAGS-tst-armtlsdescextlazymod.c += -Dstatic= CFLAGS-tst-armtlsdesclocmod.c += -mtls-dialect=gnu2 CFLAGS-tst-armtlsdescextnowmod.c += -mtls-dialect=gnu2 CFLAGS-tst-armtlsdescextlazymod.c += -mtls-dialect=gnu2 +CFLAGS-tst-armv7memcpybign.c += -mtls-dialect=gnu2 LDFLAGS-tst-armtlsdescextnowmod.so += -Wl,-z,now tst-armtlsdescloc-ENV = LD_BIND_NOW=1 tst-armtlsdescextnow-ENV = LD_BIND_NOW=1 tst-armtlsdescextlazy-ENV = LD_BIND_NOW=1 +tst-armv7memcpybign-ENV = LD_BIND_NOW=1 $(objpfx)tst-armtlsdescloc: $(objpfx)tst-armtlsdesclocmod.so $(objpfx)tst-armtlsdescextnow: $(objpfx)tst-armtlsdescextnowmod.so $(objpfx)tst-armtlsdescextlazy: $(objpfx)tst-armtlsdescextlazymod.so +$(objpfx)tst-armv7memcpybign: $(objpfx)tst-armv7memcpybignmod.so endif endif endif diff --git a/sysdeps/arm/armv7/multiarch/memcpy_impl.S b/sysdeps/arm/armv7/multiarch/memcpy_impl.S index bf4ac7077f..7455bdc6c7 100644 --- a/sysdeps/arm/armv7/multiarch/memcpy_impl.S +++ b/sysdeps/arm/armv7/multiarch/memcpy_impl.S @@ -268,7 +268,7 @@ ENTRY(memcpy) mov dst, dstin /* Preserve dstin, we need to return it. */ cmp count, #64 - bge .Lcpy_not_short + bhs .Lcpy_not_short /* Deal with small copies quickly by dropping straight into the exit block. */ @@ -351,10 +351,10 @@ ENTRY(memcpy) 1: subs tmp2, count, #64 /* Use tmp2 for count. */ - blt .Ltail63aligned + bls .Ltail63aligned cmp tmp2, #512 - bge .Lcpy_body_long + bhs .Lcpy_body_long .Lcpy_body_medium: /* Count in tmp2. */ #ifdef USE_VFP @@ -378,7 +378,7 @@ ENTRY(memcpy) add src, src, #64 vstr d1, [dst, #56] add dst, dst, #64 - bge 1b + bhs 1b tst tmp2, #0x3f beq .Ldone @@ -412,7 +412,7 @@ ENTRY(memcpy) ldrd A_l, A_h, [src, #64]! strd A_l, A_h, [dst, #64]! subs tmp2, tmp2, #64 - bge 1b + bhs 1b tst tmp2, #0x3f bne 1f ldr tmp2,[sp], #FRAME_SIZE @@ -482,7 +482,7 @@ ENTRY(memcpy) add src, src, #32 subs tmp2, tmp2, #prefetch_lines * 64 * 2 - blt 2f + bls 2f 1: cpy_line_vfp d3, 0 cpy_line_vfp d4, 64 @@ -494,7 +494,7 @@ ENTRY(memcpy) add dst, dst, #2 * 64 add src, src, #2 * 64 subs tmp2, tmp2, #prefetch_lines * 64 - bge 1b + bhs 1b 2: cpy_tail_vfp d3, 0 diff --git a/sysdeps/arm/tst-armv7memcpybign.c b/sysdeps/arm/tst-armv7memcpybign.c new file mode 100644 index 0000000000..c9f0873c90 --- /dev/null +++ b/sysdeps/arm/tst-armv7memcpybign.c @@ -0,0 +1,54 @@ +/* Test scenes where ARMv7 memcpy parameter num is very large. + Copyright (C) 2020 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, see + <https://www.gnu.org/licenses/>. */ + +#include <stdio.h> +#include <stdlib.h> +#include <signal.h> +#include <string.h> + +int g_ret = 0; + +void +sigsegv_handle(int signum) +{ + printf("Enter sigsegv_handle function\n"); + g_ret = signum; + exit(0); +} + +int +memcpy_big_n (void) +{ + char buf[100] = {0}; + memcpy(buf, "abcd", 0x80000000); +} + +int +do_test (void) +{ + signal(SIGSEGV, sigsegv_handle); + memcpy_big_n(); + if (g_ret == 0) + return 1; + else + return 0; +} + +#define TEST_FUNCTION do_test () +#include "../test-skeleton.c" +
In ARMv7, the memcpy() implementation allows for program execution to continue in scenarios where a segmentation fault or crash should have occurred. The dangers occur in that subsequent execution and iterations of this code will be executed with this corrupted data. Such as, we use 'memcpy' copy 0x80000000 byte to buffer(The buffer size is 100 bytes), it didn't crash. Reference link: https://sourceware.org/bugzilla/attachment.cgi?id=12334&action=edit Signed-off-by: Yan Zhu <zhuyan34@huawei.com> --- sysdeps/arm/Makefile | 6 +++- sysdeps/arm/armv7/multiarch/memcpy_impl.S | 14 ++++---- sysdeps/arm/tst-armv7memcpybign.c | 54 +++++++++++++++++++++++++++++++ 3 files changed, 66 insertions(+), 8 deletions(-) create mode 100644 sysdeps/arm/tst-armv7memcpybign.c -- 2.12.3