* 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
commit 2f530de168
("s390: Reorganize assembly") introduced new header
(similar to other arches) but did not add it to source
tarball.
As a result build from 'make dist' tarballs failed as:
```
../src/s390/ffi.c:34:10: fatal error: internal.h: No such file or directory
#include "internal.h"
^~~~~~~~~~~~
```
To fix it the change adds file to 'Makefile.am'.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
In eaa59755fc, macros from `unix64.S` were extracted into `asmnames.h` to be used with `win64.S` as well. As such these are required by `unix64.S`, which fails to build without them.
When running `make dist`, `configure.host` would not result in the distribution tarball, however `configure` would try to read it, and as such the tarball would not be buildable.
At the same time, we must bump the (major) ABI version. This needed to be
done anyway due to ABI breakage in the AArch64 port (see 12cf89ee and the
corresponding GCC PR70024).
An earlier patch added --disable-docs, but went too far, making it
impossible to build the docs.
It turns out that Automake seemingly has a bug preventing the
conditional build of an info file. So, this patch works around the
bug by putting the info_TEXINFOS rule into a new doc/Makefile.am.
Tested by building with and without --disable-docs and looking for the
existence of doc/libffi.info.
This eliminates the AM_CONDITIONAL ugliness, which eliminates
just a bit of extra boilerplate for a new target.
At the same time, properly categorize the EXTRA_DIST files
into SOURCES and HEADERS, for the generation of ctags.
It's impossible to call between v8 and v9 ABIs, because of the stack bias
in the v9 ABI. So let's not pretend it's just not implemented yet. Split
the v9 code out to a separate file.
The register windows prevent ffi_call from setting up the entire stack
frame the assembly, but we needn't make an indirect call back to prep_args.
Move everything into sysv.S, removing win32.S and freebsd.S.
Handle all abis with a single ffi_closure_inner function.
Move complexity of the raw THISCALL trampoline into assembly
instead of the trampoline itself.
Only push the context for the REGISTER abi; let the rest
receive it in a register.
This patch adds support for the OpenRISC architecture.
(http://opencores.org/or1k/Main_Page)
This patch has been tested under Linux with QEMU-user emulation support.
- 32 Bit
- big endian
- delayed instructions
This is the only available configuration under Linux.
The description of the ABI can be found on the official website.
Is passes the testsuite except of the unwindtest_ffi_call.cc
testcase, which seems to be a problem of gcc and not libffi.
Some testcases of the gcc testsuite still fail.
Signed-off-by: Sebastian Macke <sebastian@macke.de>
This was originally done in PR #84, except the change was made to Makefile.in instead of Makefile.am and was therefore reverted the next time the files were regenerated.
Linux supports the stdcall calling convention, either via functions
explicitly declared with the stdcall attribute, or via code compiled
with -mrtd which effectively makes stdcall the default.
This introduces FFI_STDCALL, FFI_THISCALL, and FFI_FASTCALL on
non-Windows x86-32 platforms, as non-default calling conventions.
code, and makes it possible to link code compiled with different
options to those used to compile libffi. For example, a
-mlong-double-128 libffi can be used with -mlong-double-64 code.
Using the return value area as a place to pass parameters wasn't such
a good idea, causing a failure of cls_ulonglong.c. I didn't see this
when running the mainline gcc libffi testsuite because that version of
the test is inferior to the upstreamm libffi test.
Using NUM_FPR_ARG_REGISTERS rather than NUM_FPR_ARG_REGISTERS64 meant
that a parameter save area could be allocated before it was strictly
necessary. Wrong but harmless. Found when splitting apart ffi.c
into 32-bit and 64-bit support.
This adds support for the ARC architecture to libffi. DesignWare ARC
is a family of processors from Synopsys, Inc.
This patch has been tested on a little-endian system and passes
the testsuite.
Signed-off-by: Mischa Jonker <mjonker@synopsys.com>
