BTW RISC-V Linux is now under patch review for upstreaming into Linux kernel as it is a
dependency for upstreaming glibc, so the ABI is essentially frozen:
On 28 May 2017, at 11:19 AM, Michael Clark
I’ve restarted the musl port for RISC-V based on this tree (which appeared to be the most
I have a pull request against that tree that has some fixes and merges upstream, but is
still parented against lluixhi
I also have a branch with the same changes rebased against musl upstream git.
I obviously can’t make a pull request with a rebased tree so I have two branches, one
parented to musl-riscv and the other parented to musl upstream.
When I started, the tree did not compile due to a change in definition of long double to
float128. I got the tree to compile by bringing in the QP changes but busybox linked
against the resulting lib would fail with permission denied errors. I found that the
stat.h was not the asm-generic version. RISC-V does not have it’s own syscall table and
just uses the version in asm-generic, likewise for the stat structure. It seems the tree
might have imported stat.h from another arch or been based on an earlier riscv-linux. I’ve
brought in the generic versions from aarch64. The tree can now build a working busybox on
a relatively recent riscv-linux tree i.e. Jan-2017, and it should work on latest
riscv-linux as I don’t believe there have been any recent ABI breaks.
So the port now passes the "busybox will run” test. Next on the list is to review
the atomics. I have a commit I am preparing that defines a_cas similarly to aarch64 with
load reserved store conditional. I’d also like to learn how to use the libc test suite.
BTW Some of the RISC-V developers have asked why musl doesn’t use GCC atomic builtins?
> On 9 Dec 2016, at 1:36 PM, Alan Pillay <alanppillay4(a)gmail.com
> What is the current status of musl on RISC-V?
> This was the last time I heard about it, but it has been many months since.
>> Thanks to the folks, I passed the mid-term evaluation. Now it is about
>> time to publish the fifth progress report on porting musl on RISC-V.
>> Last week, the toolchain itself has been built for RISC-V and running
>> on Spike, and libc-test  can be executed with it now. I posted the
>> result of tests on . The REPORT.txt file contains all error
>> messages of failed tests, both run-time ones and compile-time ones.
>> Some failures are expected since musl on x86_64 also does the same
>> ones (e.g. errors in src/api/fcntl.c), but there are some unexpected
>> errors too. I guess that the "warning: <the name of a header> is
>> shorter than expected" warning indicates bugs in arch-dependent part
>> of I/O functions or system calls (or kernel?) and it causes syntax
>> errors in the same compilation unit.
>> Moreover, some tests triggers a "signal 11" error (segmentation fault)
>> in libc. I added some logs to . They are bugs in the port,
>> obviously. I am working on them.
>> The good news is, anyway, some results are *better than x86_64*,
>> especially in math functions :-)
>> (probably the cause is the difference in the floating-point precision,
>> though. it is usual in float tests...)
>> It takes long, long time to get but finally I have a (seems-to-be)
>> working test suite for the port. I will continue to debug and fix the
>> port using the result. Stay tuned!
>> : http://nsz.repo.hu/git/?p=libc-test
>> : https://gist.github.com/omasanori/ee828369aea844ac7fdfdc8362953299
>> Masanori Ogino