[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-id: <405DCB5E-B096-477D-BE47-ABE85C34D97B@mac.com>
Date: Sun, 28 May 2017 11:24:53 +1200
From: Michael Clark <michaeljclark@....com>
To: musl@...ts.openwall.com
Cc: Alan Pillay <alanppillay4@...il.com>, lowrisc-dev@...ts.lowrisc.org
Subject: Re: Re: [lowrisc-dev] Weekly Report of Porting musl to RISC-V
Project #5
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:
- https://lkml.org/lkml/2017/5/22/1058 <https://lkml.org/lkml/2017/5/22/1058>
> On 28 May 2017, at 11:19 AM, Michael Clark <michaeljclark@....com> wrote:
>
> Hi,
>
> I’ve restarted the musl port for RISC-V based on this tree (which appeared to be the most recent):
>
> - https://github.com/lluixhi/musl-riscv <https://github.com/lluixhi/musl-riscv>
>
> I have a pull request against that tree that has some fixes and merges upstream, but is still parented against lluixhi
>
> - https://github.com/lluixhi/musl-riscv/pull/3 <https://github.com/lluixhi/musl-riscv/pull/3>
>
> I also have a branch with the same changes rebased against musl upstream git.
>
> - https://github.com/rv8-io/musl-riscv/tree/musl-upstream <https://github.com/rv8-io/musl-riscv/tree/musl-upstream>
>
> 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? e.g.
>
> - https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html <https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html>
>
> Regards,
> Michael
>
>> On 9 Dec 2016, at 1:36 PM, Alan Pillay <alanppillay4@...il.com <mailto:alanppillay4@...il.com>> wrote:
>>
>> 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.
>> Regards.
>>
>>> Hello,
>>>
>>> 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 [1] can be executed with it now. I posted the
>>> result of tests on [2]. 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 [2]. 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!
>>>
>>>
>>> [1]: http://nsz.repo.hu/git/?p=libc-test <http://nsz.repo.hu/git/?p=libc-test>
>>> [2]: https://gist.github.com/omasanori/ee828369aea844ac7fdfdc8362953299 <https://gist.github.com/omasanori/ee828369aea844ac7fdfdc8362953299>
>>>
>>> --
>>> Masanori Ogino
>>
>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
