Re: [PATCH v2] memcpy: use bhs/bls instead of bge/blt [BZ #25620]

[Joseph Myers <joseph@codesourcery.com>]

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 S. Myers
joseph@codesourcery.com