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>
libffi test framework already flagged failures as:
```
FAIL: libffi.call/cls_double_va.c -W -Wall -Wno-psabi -O0 output pattern test, is 7.0
res: 4
0.0
res: 4
? should match 7.0
?es: 4
?.0
res: 4
```
Failure happens here at
```c
// testsuite/libffi.call/cls_double_va.c
...
char* format = "%.1f\n";
double doubleArg = 7;
...
CHECK(ffi_prep_closure_loc(pcl, &cif, cls_double_va_fn, NULL,
code) == FFI_OK);
res = ((int(*)(char*, ...))(code))(format, doubleArg);
```
libffi expects 'doubleArg' to be located in 'f9' (second FP argument) but
gcc placed it to 'r33' (second GR).
ia64 software [1] manual described argument passing ABI in
"8.5.2 Register Parameters" as:
"""
If an actual parameter is known to correspond to a floating-point
formal parameter, the following rules apply:
a) The actual parameter is passed in the next available floating-point
parameter register, if one is available. Floating-point parameter
registers are allocated as needed from the range f8-f15, starting
with f8.
b) If all available floating-point parameter registers have been used,
the actual parameter is passed in the appropriate general register(s).
(This case can occur only as a result of homogeneous floating-point
aggregates, described below.)
If a floating-point actual parameter is known to correspond to
a variable-argument specification in the formal parameter list,
the following rule applies:
c) The actual parameter is passed in the appropriate general
register(s).
If the compiler cannot determine, at the point of call,
whether the corresponding formal parameter is a varargs parameter,
it must generate code that satisfies both of the above conditions.
(The compiler’s determination may be based on prototype declarations,
language standard assumptions, analysis, or other user options or
information.)
"""
We have [c] case here and gcc uses only GR for parameter passing.
The change binds known variadic arguments ro GRs instead of FPs as those
are always expected to be initialized for all variadic call types.
This fixes all 10 failures on ia64-unknown-linux-gnu:
```
=== libffi Summary ===
-# of expected passes 1945
-# of unexpected failures 10
+
+# of expected passes 1955
```
[1]: https://www.intel.com/content/dam/www/public/us/en/documents/guides/itanium-software-runtime-architecture-guide.pdf
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
commit 6e8a446083
added FFI_TYPE_COMPLEX value type (comes after FFI_TYPE_POINTER)
ia64 ffi_closure_unix reiles on the ordering of
FFI_ enums as ia64 has ia64-specific FFI types:
small struct and FPU extesions.
As a result all tests handling small structs broke.
The change fixes dispatch table by adding (no-op)
FFI_TYPE_COMPLEX entry
This has positive effect of unbreaking most tests
on ia64:
=== libffi Summary ===
-# of expected passes 1595
-# of unexpected failures 295
+# of expected passes 1930
+# of unexpected failures 10
# of unsupported tests 30
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Anthony Green
Sergei Trofimovich
Anthony Green