* 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>
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>
The assembly single-line comments swallowed up the remaining assembly
code of the macros due to lack of line-endings.
This is a regression introduced in b7f6d7a.
MIPS release changed encodes of some instructions, include ll/sc etc.
if .set mips4 on mips r6, as will generate some wrong encode of some instructions.
Rather than relying on the stack being 0'ed out always, do it manually.
The stack generally happened to be zero, and because the compiler
realizes that the tests are dealing with chars truncates the read value.
However, the top 3 nibbles of the value are undefined and may be
non-zero. The indirection level caused a null-pointer dereference.
Explicitly scribbling on the stack during the allocation causes test
failures without the original zexting behaviour.
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>
The closure function (invoked as closure->fun in ffi_closure_XXX_inner)
will only populate the actual number of bytes for the true return type,
which may be a character. This leaves garbage on the stack when the
assembly closure function (i.e. ffi_closure_XXX) reads the return value
off of the stack into r0 as a 4-byte value. ffi_closure_XXX always
leaves room for at least 4 bytes here, so we can safely set them to 0.
Otherwise, if there is garbage in any of these bytes, these end up in r0
and in the returned value as well.
- Add missing files for desktop platforms in generate-darwin-source-and-headers.py, and in the Xcode project.
- Add a static library target for macOS.
- Fix "implicit conversion loses integer precision" warnings for iOS mad macOS targets.
By using VM_FLAGS_OVERWRITE there is no need for speculatively
allocating on a page we just deallocated. This approach eliminates the
race-condition and gets rid of the retry logic.
The patch for o32.S is taken from OpenWrt packages repo 3a7a4bf "libffi:
fix MIPS softfloat build issue with current binutils"
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
