Bug 479699

Hi,

The ARM Architecture Procedure Call Standard relaxed the limitations on memory
accesses below the stack pointer in 2018Q4:

| 6.2.1.3 Stack probing
| In order to ensure stack integrity a process may emit stack probes immediately
| prior to allocating additional stack space (moving SP from SP_old to SP_new).
| Stack probes must be in the region of [SP_new, SP_old - 1] and may be either
| read or write operations. The minimum interval for stack probing is defined by
| the target platform but must be a minimum of 4KBytes. No recoverable data can
| be saved below the currently allocated stack region.

See https://github.com/ARM-software/abi-aa/blob/2a70c42d62e9c3eb5887fa50b71257f20daca6f9/aapcs32/aapcs32.rst#6213stack-probing

Currently, valgrind considers all memory accesses below SP as errors, see for
example: https://lists.debian.org/debian-arm/2023/12/msg00002.html

GCC implements the AAPCS rules when using stack-clash protection, so please
consider updating valgrind accordingly.

Additionally, valgrind may segfault when debugging programs built
with stack-clash-protection turned on. For example:

 valgrind --track-origins=yes --leak-check=full apt-get update
 [...]
 ==3102620== Process terminating with default action of signal 11 (SIGSEGV)
 ==3102620==  Access not within mapped region at address 0xFEDCBDAC
 ==3102620==    at 0x49476E8: ReadMessages(int, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&) (strutl.cc:888)

See https://people.debian.org/~ema/valgrind-segfault-apt-get-update.log for
full output.

Disassembled code at https://people.debian.org/~ema/apt-scp-armhf.log. The
memory location pointed at by r12 is out of the stack.

Another example of valgrind segfaulting when checking programs built with
stack-clash-protection on 32bit arm is at
https://bugzilla.redhat.com/show_bug.cgi?id=1522678