Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
New RISC-V port #281
This patch adds support for RISC-V. I sent it to the ML earlier but was requested to create a PR instead.
I did not write the code in this patch; it is a cleaned up and rebased version of a port by Michael Knyszek et al of UC Berkeley.
RISC-V is a free and open standard instruction set architecture originally developed at UC Berkeley and now seeing significant interest from independent hardware vendors, with interoperable prototypes from several independent groups. Alex Bradbury's recent RFC to the LLVM community has a much better explanation of what RISC-V is and why you should care about it.
While the privileged architecture is still in some flux, the architecture which is visible to user space and the C calling convention have been unchanged in nearly two years and are now considered frozen, so ports like this one are very likely to remain valid.
I am interested in being the responsible party to get this code into a mergable condition. I am familiar with the RISC-V ISA and calling convention and with libffi's broad principles of operation, but not with the details of libffi internals.
How shall we proceed?
I've run the full testsuite on qemu system and user emulation. The user emulation is the easiest way to follow along, although it's still a bit touchy. Follow the instructions on https://hub.docker.com/r/sorear/fedora-riscv-wip/ to set up an emulated RISC-V user environment (assuming you have an amd64 Linux host).
Next, build the latest qemu-user from https://github.com/arsv/riscv-qemu for an important bugfix. Build it with
Next, install the following packages in the container:
Source noarch packages from koji, riscv64 packages from https://github.com/rwmjones/fedora-riscv.
Once the environment is set up, it is possible to check out the code, (you may need to hack config.guess to return the correct result),
So it turns out there have been a couple changes to the floating-point ABI implemented in gcc:
None of these changes affect the realized ABI for 32-bit or 64-bit hardfloat code that doesn't use long double.
I'm going to continue work on the libffi cleanup for the old ABI, but I'll probably need to update it at some point.
of expected passes 1680
of unexpected failures 215
of unsupported tests 30
Apologies for the long wait everyone. I've addressed the review feedback and updated for the gcc 7 ABI, which turned into a nearly complete rewrite of the patch; on the positive side it is significantly shorter now.
The patch has been tested, and passes all non-unsupported tests, using gcc 7.2.0 and riscv/riscv-qemu@qemu-upstream-v4 for the 32-bit soft float, 32-bit hard float, 64-bit soft float, and 64-bit hard float configuration. Several other combinations are expected to be supported by the code but are not tested.
There is a small amount of cruft in the ffitarget.h to maintain ABI compatibility with the patch version I posted earlier. It can be removed at the next SONAME bump, or, somewhat riskier, now. (I don't know if any significant body of risc-v binaries built against libffi.so.7 exists. Fedora is still on libffi.so.6 and would not be affected.)
firstname.lastname@example.org and email@example.com are also available.
Build and test instructions will be posted after I have verified them.
That doesn't pass the python3 tests:
Re-running test 'test_ctypes' in verbose mode
@andreas-schwab Find the list of architectures that get
Once riscv/riscv-gnu-toolchain#325 is merged something like the following script (UNTESTED!) will work:
@atgreen Updated README to mention RISC-V. The columns are a little bit too narrow to enumerate hard float / soft float as well as 32 / 64, and I'm not sure if I should mention that only 64-bit hard float has been tested "natively" (qemu-system-riscv64), the others using a cross-compiler.
Also added a configure.host bit which I missed earlier (I didn't catch it because I forgot to rerun autogen.sh after switching from 3.1 to master, I'm surprised this worked at all.)
Might make sense to squash at this point?
Also regarding testing, we are currently UNSUPPORTED on the Go closure and complex number tests.