Re: [PATCH v2 00/12] RISC-V glibc port for the 32 bit

[Joseph Myers <joseph at codesourcery dot com>]

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.

* 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.

* 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).

* 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.

* 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.

-- 
Joseph S. Myers
joseph@codesourcery.com