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

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

[Masanori Ogino]

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: [musl] Weekly Report of Porting musl to RISC-V Project #5

[Szabolcs Nagy]

* Masanori Ogino <masanori.ogino@gmail.com> [2016-07-03 09:42:00 +0900]:
> 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.

try to figure out this error:

cc1: warning: src/regression/printf-fmt-g-zeros.c is shorter than expected
In file included from src/regression/printf-fmt-g-zeros.c:3:0:
/usr/include/stdio.h:8:22: warning: /usr/include/features.h is shorter than expected
 #include <features.h>
                      ^
In file included from /usr/include/stdio.h:22:0,
                 from src/regression/printf-fmt-g-zeros.c:3:
/usr/include/bits/alltypes.h:46:19: error: missing ')' after "defined"
 #if defined(__NEED_suseconds_t) && !defined(__DEFINED_suseconds_t)
                   ^

is this a native toolchain?
i thought you would cross compile things first
(although libc-test is not set up to easily run
the tests in a simulator after cross compiling)

it might be some filesystem issue if there are
truncated files.

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

[Masanori Ogino]

Hello,

2016-07-03 23:24 GMT+09:00 Szabolcs Nagy <nsz@port70.net>:
> * Masanori Ogino <masanori.ogino@gmail.com> [2016-07-03 09:42:00 +0900]:
>> 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.
>
> try to figure out this error:
>
> cc1: warning: src/regression/printf-fmt-g-zeros.c is shorter than expected
> In file included from src/regression/printf-fmt-g-zeros.c:3:0:
> /usr/include/stdio.h:8:22: warning: /usr/include/features.h is shorter than expected
>  #include <features.h>
>                       ^
> In file included from /usr/include/stdio.h:22:0,
>                  from src/regression/printf-fmt-g-zeros.c:3:
> /usr/include/bits/alltypes.h:46:19: error: missing ')' after "defined"
>  #if defined(__NEED_suseconds_t) && !defined(__DEFINED_suseconds_t)
>                    ^
>
> is this a native toolchain?

Yes.

> i thought you would cross compile things first
> (although libc-test is not set up to easily run
> the tests in a simulator after cross compiling)
>
> it might be some filesystem issue if there are
> truncated files.

Sure. I am trying to do cross-compiled tests.

-- 
Masanori Ogino