From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11357 Path: news.gmane.org!.POSTED!not-for-mail From: Michael Clark Newsgroups: gmane.linux.lib.musl.general,gmane.comp.hardware.lowrisc.devel Subject: Re: [lowrisc-dev] Weekly Report of Porting musl to RISC-V Project #5 Date: Sun, 28 May 2017 11:19:38 +1200 Message-ID: <3E8336E8-5DAF-402C-A538-5FDCF197F169@mac.com> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_5B7F9D4D-40D7-4E3A-A351-10896835F143" X-Trace: blaine.gmane.org 1495927209 11067 195.159.176.226 (27 May 2017 23:20:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 27 May 2017 23:20:09 +0000 (UTC) Cc: musl@lists.openwall.com, lowrisc-dev@lists.lowrisc.org To: Alan Pillay Original-X-From: musl-return-11372-gllmg-musl=m.gmane.org@lists.openwall.com Sun May 28 01:20:04 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1dEl08-0002mT-2K for gllmg-musl@m.gmane.org; Sun, 28 May 2017 01:20:04 +0200 Original-Received: (qmail 22500 invoked by uid 550); 27 May 2017 23:20:07 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 22461 invoked from network); 27 May 2017 23:20:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mac.com; s=4d515a; t=1495927191; bh=MqPTStDRzPzlfByLtFH3WlZzW0e+1ujaShx9Ia/CWRQ=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=KtGpG4WA3Vtu0HAqE1RqrQ/VvyE10bXqxbgI5+w8saHoTzCwTc6aPZtyp9XN3CXgy +10m2ZAIz4W3TyBfKz7+Msb28zA354AgZVjhktNA6YigxVtcviBfsd8gggEvNJ1ivH dqNHdU62qB6rHgfQ1Sfk22iNS2Xmdo+bZknsqKqmlXA/PwEIay8H9g0p5LrIS+O++r lqU2rJs+bS3CjBMdmce/Cy6ypClYr93SZ3U4h4wgiCY9dbTI5VfpJyEXfVUWlMZVLm TAe5Sjj1pIexSsEbnoq0rc9Yh/UsVGZC+RCSojF3QAbPk8cXHUgnBsSHpJLfUNcoIK 4pGkeuRiVEwEQ== X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-27_20:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1705270456 In-reply-to: X-Mailer: Apple Mail (2.3273) Xref: news.gmane.org gmane.linux.lib.musl.general:11357 gmane.comp.hardware.lowrisc.devel:696 Archived-At: --Apple-Mail=_5B7F9D4D-40D7-4E3A-A351-10896835F143 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I=E2=80=99ve 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=E2=80=99t 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=E2=80=99s 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=E2=80=99ve 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=E2=80=99t believe there have = been any recent ABI breaks. So the port now passes the "busybox will run=E2=80=9D 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=E2=80=99d also like to learn how to use the libc test suite. BTW Some of the RISC-V developers have asked why musl doesn=E2=80=99t = use GCC atomic builtins? e.g. - https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html = Regards, Michael > On 9 Dec 2016, at 1:36 PM, Alan Pillay wrote: >=20 > 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. >=20 >> Hello, >>=20 >> 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. >>=20 >> 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. >>=20 >> 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: 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. >>=20 >> 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. >>=20 >> 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...) >>=20 >> 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! >>=20 >>=20 >> [1]: http://nsz.repo.hu/git/?p=3Dlibc-test >> [2]: = https://gist.github.com/omasanori/ee828369aea844ac7fdfdc8362953299 >>=20 >> -- >> Masanori Ogino >=20 --Apple-Mail=_5B7F9D4D-40D7-4E3A-A351-10896835F143 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi,

I=E2=80=99ve 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=E2=80=99t 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=E2=80=99s 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=E2=80=99ve 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=E2=80=99t believe there have = been any recent ABI breaks.

So the port now passes the "busybox will run=E2=80=9D 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=E2=80=99d also like to learn how to use the libc = test suite.

BTW = Some of the RISC-V developers have asked why musl doesn=E2=80=99t use = GCC atomic builtins? e.g.

- https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.ht= ml

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=3Dlibc-test
[2]: = https://gist.github.com/omasanori/ee828369aea844ac7fdfdc8362953= 299

--
Masanori Ogino


= --Apple-Mail=_5B7F9D4D-40D7-4E3A-A351-10896835F143--