This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Joseph Myers <> 於 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
> <> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]