This change fixes libffi.call/struct10.c failure on ia64:
FAIL: libffi.call/struct10.c -W -Wall -Wno-psabi -O0 execution test
.Lst_small_struct handles returns for structs less than 32 bytes
(following ia64 return value ABI [1]). Subroutine does roughly the
following:
```
mov [sp+0] = r8
mov [sp+8] = r9
mov [sp+16] = r10
mov [sp+24] = r11
memcpy(destination, source=sp, 12);
```
The problem: ia64 ABI guarantees that top 16 bytes of stack are
scratch space for callee function. Thus it can clobber it. [1]
says (7.1 Procedure Frames):
"""
* Scratch area. This 16-byte region is provided as scratch storage
for procedures that are called by the current procedure. Leaf
procedures do not need to allocate this region. A procedure may
use the 16 bytes at the top of its own frame as scratch memory,
but the contents of this area are not preserved by a procedure call.
"""
In our case 16 top bytes are clobbered by a PLT resolver when memcpy()
is called for the first time. As a result memcpy implementation reads
already clobbered data frop top of stack.
The fix is simple: allocate 16 bytes of scrats space prior to memcpy()
call.
[1]: https://www.intel.com/content/dam/www/public/us/en/documents/guides/itanium-software-runtime-architecture-guide.pdf
Bug: https://bugs.gentoo.org/634190
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
;;
.Lst_small_struct:
- add sp = -16, sp
cmp.lt p6, p0 = 8, in3
cmp.lt p7, p0 = 16, in3
cmp.lt p8, p0 = 24, in3
(p8) st8 [r18] = r11
mov out1 = sp
mov out2 = in3
+ ;;
+ // ia64 software calling convention requires
+ // top 16 bytes of stack to be scratch space
+ // PLT resolver uses that scratch space at
+ // 'memcpy' symbol reolution time
+ add sp = -16, sp
br.call.sptk.many b0 = memcpy#
;;
mov ar.pfs = loc0