This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2 00/12] RISC-V glibc port for the 32 bit
- From: Zong Li <zongbox at gmail dot com>
- To: joseph at codesourcery dot com
- Cc: Zong Li <zong at andestech dot com>, Palmer Dabbelt <palmer at dabbelt dot com>, darius at bluespec dot com, Andrew Waterman <andrew at sifive dot com>, dj at redhat dot com, rth at twiddle dot net, libc-alpha at sourceware dot org, rth7680 at gmail dot com
- Date: Wed, 18 Jul 2018 16:31:13 +0800
- Subject: Re: [PATCH v2 00/12] RISC-V glibc port for the 32 bit
- References: <cover.1531801545.git.zong@andestech.com> <alpine.DEB.2.20.1807172213410.19759@digraph.polyomino.org.uk>
Joseph Myers <joseph@codesourcery.com> 於 2018年7月18日 週三 上午6:28寫道:
>
> On Tue, 17 Jul 2018, Zong Li wrote:
>
> > This patch set contains the glibc port for the 32 bit RISC-V. I ran the glibc
> > test suite on QEMU, and remained the failed cases which caused by environment
> > issue like 64 bit glibc port. In addition, there are some math test cases
> > need to be checked but it looks unlike glibc's problem.
>
> In the course of RISC-V port review (roughly, June 2017 through January
> 2018), there were many discussions that included advice, and resulted in
> agreement, on how various issues related to the port should be handled.
>
> If you are now taking over work on part of the port from the people who
> originally submitted it and later deferred it to a later version, it is
> your responsibility to familiarise yourself with those discussions and
> ensure that the patch submissions are consistent with that advice and
> agreement. Here are a few examples, but you will need to go through the
> past discussions to find any others.
>
I had gone through the discussion quickly from the patch v2 to patch v7 before,
but it seems a little bit rough at that time.
> * New port submissions should come with test results - both the summary
> from "make check" output, listing non-PASS results and statistics, for
> each of the supported configurations (both compilation and execution tests
> - whether building natively, or cross-testing with test-wrapper
> specified), and a link to externally-hosted test logs with the full .out
> and .test-result files for the non-PASS tests and the full "make check"
> output. As I understand it, you are proposing three new configurations,
> so there would be three such sets of results. Please follow the example
> of the submissions of the later versions of the RISC-V port. The test
> results should be with upstream GCC, binutils and Linux kernel versions
> (of your choice, but specified in the port submission). "looks unlike
> glibc's problem" is simply not enough. We need the actual results,
> hopefully with analysis to justify why they don't indicate problems in the
> port.
I will give the more detail about this and a link for the test result
on later version.
>
> * New port submissions need to use new minimum symbol versions. This port
> can't use GLIBC_2.27 because it wasn't in 2.27. It needs to use
> GLIBC_2.28 (or GLIBC_2.29 after 2.28 is out, given the risks of putting
> this into 2.28).
>
I will change the minimum version for 32-bit port.
> * 32-bit RISC-V support was omitted from 2.27 because the Linux kernel
> support was in too poor shape to be able to run the testsuite. Thus, you
> need to confirm what upstream Linux kernel version had good-enough support
> for 32-bit RISC-V, and set arch_minimum_kernel accordingly.
>
I had submitted some patches for 32-bit Linux on RISC-V. For now, the
upstream kernel
can build successfully and run the glibc testsutie.
> * Please review the list at
> <https://sourceware.org/ml/libc-alpha/2018-01/msg00008.html> of pieces
> relevant to multi-ABI systems. Is it still the case that Linux does not
> support RV32I code executing on RV64I processors? If so, much of that may
> not *yet* be relevant, but you still need to be aware of it and ready to
> add the support as and when Linux support is available. In any case, that
> list needs careful review to make sure you've changed whichever places are
> relevant to change in that regard.
Yes, I had checked that last month, the Linux still doesn't support RV32I code
executing on RV64I processors, there need some modification to support
that in kernel.
I will keep track this.
> --
> Joseph S. Myers
> joseph@codesourcery.com