From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11358 Path: news.gmane.org!.POSTED!not-for-mail From: Michael Clark Newsgroups: gmane.linux.lib.musl.general,gmane.comp.hardware.lowrisc.devel Subject: Re: Re: [lowrisc-dev] Weekly Report of Porting musl to RISC-V Project #5 Date: Sun, 28 May 2017 11:24:53 +1200 Message-ID: <405DCB5E-B096-477D-BE47-ABE85C34D97B@mac.com> References: <3E8336E8-5DAF-402C-A538-5FDCF197F169@mac.com> 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=_B9240C6E-A6F7-4DA3-9063-1F599EA3D3B1" X-Trace: blaine.gmane.org 1495927515 4663 195.159.176.226 (27 May 2017 23:25:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 27 May 2017 23:25:15 +0000 (UTC) Cc: Alan Pillay , lowrisc-dev@lists.lowrisc.org To: musl@lists.openwall.com Original-X-From: musl-return-11373-gllmg-musl=m.gmane.org@lists.openwall.com Sun May 28 01:25:10 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 1dEl53-00014o-QA for gllmg-musl@m.gmane.org; Sun, 28 May 2017 01:25:09 +0200 Original-Received: (qmail 26419 invoked by uid 550); 27 May 2017 23:25:13 -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 26395 invoked from network); 27 May 2017 23:25:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mac.com; s=4d515a; t=1495927500; bh=R2GZbB0D90/oOTXKyJvL6BnAu5ZHI4O/LNnp2s8j5rg=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=MXVDmsHykzr9DM1fx/wjogibARCIchZuqAZGy2lPLZtxTHCffF8ekWCnYKa8yRiQk GEDwH2rMXlVrU1sscHbj8hdqtQU82Tu5IAfJjv58BIXxwJ7ulRbqJiP+Qv95rymRvW JHqbNCo5a7+ZYIvu24yfX8Vwij8rFZR+dnj0ioe0xdwvZaN4dJKRmTSRV+W+4nKF9b 9oAtNQAQ7PF2aXqHh6uyiwJBlktuPNZC+zwra0pXQ5STK7yF3m1iI4TNI7nKXYO1ia fMw6npxFqzf6C64xyrJoo6PiRMZeFVPGHlEuOoEPkxxdZPWPO7Y0kFA2O169fwb38r 9oo8x0GnZtthQ== 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=14 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1705270457 In-reply-to: <3E8336E8-5DAF-402C-A538-5FDCF197F169@mac.com> X-Mailer: Apple Mail (2.3273) Xref: news.gmane.org gmane.linux.lib.musl.general:11358 gmane.comp.hardware.lowrisc.devel:697 Archived-At: --Apple-Mail=_B9240C6E-A6F7-4DA3-9063-1F599EA3D3B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 = > On 28 May 2017, at 11:19 AM, Michael Clark = wrote: >=20 > Hi, >=20 > I=E2=80=99ve restarted the musl port for RISC-V based on this tree = (which appeared to be the most recent): >=20 > - https://github.com/lluixhi/musl-riscv = >=20 > I have a pull request against that tree that has some fixes and merges = upstream, but is still parented against lluixhi >=20 > - https://github.com/lluixhi/musl-riscv/pull/3 = >=20 > I also have a branch with the same changes rebased against musl = upstream git. >=20 > - https://github.com/rv8-io/musl-riscv/tree/musl-upstream = >=20 > 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. >=20 > 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. >=20 > 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. >=20 > BTW Some of the RISC-V developers have asked why musl doesn=E2=80=99t = use GCC atomic builtins? e.g. >=20 > - https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html = >=20 > Regards, > Michael >=20 >> 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 >=20 --Apple-Mail=_B9240C6E-A6F7-4DA3-9063-1F599EA3D3B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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

On = 28 May 2017, at 11:19 AM, Michael Clark <michaeljclark@mac.com> wrote:

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=_B9240C6E-A6F7-4DA3-9063-1F599EA3D3B1--