* Add RISC-V support
This patch adds support for the RISC-V architecture (https://riscv.org).
This patch has been tested using QEMU user-mode emulation and GCC 7.2.0
in the following configurations:
* -march=rv32imac -mabi=ilp32
* -march=rv32g -mabi=ilp32d
* -march=rv64imac -mabi=lp64
* -march=rv64g -mabi=lp64d
The ABI currently can be found at
https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md .
* Add RISC-V to README
* RISC-V: fix configure.host
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>
The bug originally was discovered in https://bugs.gentoo.org/634190
where complicated callback was returning invalid data on ia64.
This change adds minimal reproducer that fails only on ia64 as:
FAIL: libffi.call/struct10.c -W -Wall -Wno-psabi -O0 execution test
FAIL: libffi.call/struct10.c -W -Wall -Wno-psabi -O2 execution test
FAIL: libffi.call/struct10.c -W -Wall -Wno-psabi -O3 execution test
FAIL: libffi.call/struct10.c -W -Wall -Wno-psabi -Os execution test
Test passes on amd64. The fix is in the following commit.
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>
Anthony Green
Stef O'Rear
Andreas Schwab
Sergei Trofimovich