Re: Weekly Report of Porting musl to RISC-V Project #5

Re: Weekly Report of Porting musl to RISC-V Project #5

[Alan Pillay]

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
> [2]: https://gist.github.com/omasanori/ee828369aea844ac7fdfdc8362953299
>
> --
> Masanori Ogino

Re: Re: Weekly Report of Porting musl to RISC-V Project #5

[Rich Felker]

On Thu, Dec 08, 2016 at 10:36:44PM -0200, Alan Pillay 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.

The student (Masanori Ogino) disappeared and hasn't been in contact
since. I'd really like to follow up and see what we can salvage from
the project, as this is still a big wishlist item.

Rich


> > 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
> > [2]: https://gist.github.com/omasanori/ee828369aea844ac7fdfdc8362953299
> >
> > --
> > Masanori Ogino

Re: Re: Weekly Report of Porting musl to RISC-V Project #5

[Alan Pillay]

> The student (Masanori Ogino) disappeared and hasn't been in contact
> since

I hope he is ok.

> I'd really like to follow up and see what we can salvage from
> the project, as this is still a big wishlist item.

Awesome. RISC-V is gaining momentum.

Re: Re: Weekly Report of Porting musl to RISC-V Project #5

[Masanori Ogino]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

Hello, everyone.

At first, I'm so sorry for not finishing the project in this summer. It's
my fault.

When Rich had sent a mail asking the progress in July, I tried to send a
reply but it seems to be lost.
I had been in bad shape in this summer and autumn, but I'm getting better
little by little.

I failed to succeed the project, but I'd love to help the port even now, if
I can provide anything useful.

Again, I'm sorry for my inadequacy.

2016年12月9日(金) 10:36 Alan Pillay <alanppillay4@gmail.com>:

> > The student (Masanori Ogino) disappeared and hasn't been in contact
> > since
>
> I hope he is ok.
>
> > I'd really like to follow up and see what we can salvage from
> > the project, as this is still a big wishlist item.
>
> Awesome. RISC-V is gaining momentum.
>
-- 
Masanori Ogino

[-- Attachment #2: Type: text/html, Size: 1506 bytes --]

Re: Re: Weekly Report of Porting musl to RISC-V Project #5

[Rich Felker]

On Tue, Dec 20, 2016 at 01:11:51PM +0000, Masanori Ogino wrote:
> Hello, everyone.
> 
> At first, I'm so sorry for not finishing the project in this summer. It's
> my fault.
> 
> When Rich had sent a mail asking the progress in July, I tried to send a
> reply but it seems to be lost.
> I had been in bad shape in this summer and autumn, but I'm getting better
> little by little.
> 
> I failed to succeed the project, but I'd love to help the port even now, if
> I can provide anything useful.
> 
> Again, I'm sorry for my inadequacy.

Hi. Glad to see you back. Richard Pennington (ellcc.org, rdp on #musl)
is presently looking at trying to merge the riscv port and get it
hooked up to clang/llvm/ellcc, from what I understand, so it might be
good to talk to him.

Rich

Re: [lowrisc-dev] Weekly Report of Porting musl to RISC-V Project #5

[Michael Clark]

[-- Attachment #1: Type: text/plain, Size: 3773 bytes --]

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

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

I also have a branch with the same changes rebased against musl upstream git.

- 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@gmail.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
>> [2]: https://gist.github.com/omasanori/ee828369aea844ac7fdfdc8362953299
>> 
>> --
>> Masanori Ogino
> 


[-- Attachment #2: Type: text/html, Size: 5628 bytes --]

Re: Re: [lowrisc-dev] Weekly Report of Porting musl to RISC-V Project #5

[Michael Clark]

[-- Attachment #1: Type: text/plain, Size: 4477 bytes --]

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@mac.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@gmail.com <mailto:alanppillay4@gmail.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
>> 
> 


[-- Attachment #2: Type: text/html, Size: 6461 bytes --]