[v2,00/12] RISC-V glibc port for the 32 bit

Message ID cover.1531801545.git.zong@andestech.com
Headers show
Series
  • RISC-V glibc port for the 32 bit
Related show

Message

Zong Li July 17, 2018, 5:07 a.m.
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.

There is a patch to fix the ld flags issue of tst-execstack-mod.so, it
cause the fail on some test cases on RISC-V. In the v1 patch, I don't include
this patch into patch set, in v2, I collect all patches together.

There is a patch to add lack of implementation of 128 bit for soft-fp, these
are necessary for building 32 bit RISC-V port.

Thanks everyone for the help and Palmer's efforts during this work.

Change in V2:
 - Only include the ieee754/soft-fp path in rv32/nofpu/Implies.
 - Add lack of implementation for 128 bit in soft-ft/op-8.h.
 - Include the patch which fix the ld flags of tst-execstack-mod.so.
 - Add the modification of URL of gcc's tarball.

Zong Li (12):
  Documentation for the 32 bit RISC-V port
  RISC-V: Add dynamic loader for the 32 bit
  RISC-V: Add path of library directories for the 32 bit
  RISC-V: The ABI implementation for the 32-bit
  RISC-V: Hard float support for the 32 bit
  RISC-V: Split the soft-fp into rv32 and rv64
  RISC-V: Add ABI lists
  RISC-V: Build Infastructure for the 32 bit
  Add 32 bit RISC-V to build-many-glibcs.py
  soft-fp: Add the lack of implementation for 128 bit
  Fix the ld flags not be applied to tst-execstack-mod.so
  Change URL of gcc's tarball

 NEWS                                               |    3 +
 README                                             |    1 +
 elf/Makefile                                       |    2 +-
 scripts/build-many-glibcs.py                       |   17 +-
 soft-fp/op-8.h                                     |  176 ++
 sysdeps/riscv/bits/wordsize.h                      |    4 +-
 sysdeps/riscv/nofpu/Implies                        |    1 -
 sysdeps/riscv/nofpu/libm-test-ulps                 | 2198 --------------------
 sysdeps/riscv/nofpu/libm-test-ulps-name            |    1 -
 sysdeps/riscv/nptl/bits/pthreadtypes-arch.h        |   25 +-
 sysdeps/riscv/preconfigure                         |    6 +-
 sysdeps/riscv/rv32/Implies-after                   |    1 +
 sysdeps/riscv/rv32/nofpu/Implies                   |    1 +
 sysdeps/riscv/rv32/nofpu/libm-test-ulps            |  534 +++++
 sysdeps/riscv/rv32/nofpu/libm-test-ulps-name       |    1 +
 sysdeps/riscv/rv32/rvd/Implies                     |    3 +
 sysdeps/riscv/rv32/rvd/libm-test-ulps              | 1658 +++++++++++++++
 sysdeps/riscv/rv32/rvd/libm-test-ulps-name         |    1 +
 sysdeps/riscv/rv32/rvd/s_lrint.c                   |   31 +
 sysdeps/riscv/rv32/rvd/s_lround.c                  |   31 +
 sysdeps/riscv/rv32/rvf/Implies                     |    1 +
 sysdeps/riscv/rv32/rvf/s_lrintf.c                  |   31 +
 sysdeps/riscv/rv32/rvf/s_lroundf.c                 |   31 +
 sysdeps/riscv/rv64/nofpu/Implies                   |    1 +
 sysdeps/riscv/rv64/nofpu/libm-test-ulps            | 2198 ++++++++++++++++++++
 sysdeps/riscv/rv64/nofpu/libm-test-ulps-name       |    1 +
 sysdeps/riscv/sfp-machine.h                        |   27 +-
 sysdeps/riscv/sys/asm.h                            |    5 +-
 sysdeps/unix/sysv/linux/riscv/Makefile             |    4 +-
 sysdeps/unix/sysv/linux/riscv/configure            |   39 +
 sysdeps/unix/sysv/linux/riscv/configure.ac         |    8 +
 sysdeps/unix/sysv/linux/riscv/dl-cache.h           |   15 +-
 sysdeps/unix/sysv/linux/riscv/ldconfig.h           |    2 +-
 sysdeps/unix/sysv/linux/riscv/rv32/Implies         |    3 +
 sysdeps/unix/sysv/linux/riscv/rv32/c++-types.data  |   67 +
 .../unix/sysv/linux/riscv/rv32/jmp_buf-macros.h    |   53 +
 sysdeps/unix/sysv/linux/riscv/rv32/ld.abilist      |    9 +
 .../sysv/linux/riscv/rv32/libBrokenLocale.abilist  |    1 +
 sysdeps/unix/sysv/linux/riscv/rv32/libanl.abilist  |    4 +
 sysdeps/unix/sysv/linux/riscv/rv32/libc.abilist    | 2098 +++++++++++++++++++
 .../unix/sysv/linux/riscv/rv32/libcrypt.abilist    |    7 +
 sysdeps/unix/sysv/linux/riscv/rv32/libdl.abilist   |    9 +
 sysdeps/unix/sysv/linux/riscv/rv32/libm.abilist    | 1021 +++++++++
 sysdeps/unix/sysv/linux/riscv/rv32/libnsl.abilist  |  120 ++
 .../unix/sysv/linux/riscv/rv32/libpthread.abilist  |  216 ++
 .../unix/sysv/linux/riscv/rv32/libresolv.abilist   |   79 +
 sysdeps/unix/sysv/linux/riscv/rv32/librt.abilist   |   35 +
 .../sysv/linux/riscv/rv32/libthread_db.abilist     |   40 +
 sysdeps/unix/sysv/linux/riscv/rv32/libutil.abilist |    6 +
 sysdeps/unix/sysv/linux/riscv/rv32/lockf64.c       |   70 +
 sysdeps/unix/sysv/linux/riscv/shlib-versions       |    4 +
 51 files changed, 8686 insertions(+), 2214 deletions(-)
 delete mode 100644 sysdeps/riscv/nofpu/Implies
 delete mode 100644 sysdeps/riscv/nofpu/libm-test-ulps
 delete mode 100644 sysdeps/riscv/nofpu/libm-test-ulps-name
 create mode 100644 sysdeps/riscv/rv32/Implies-after
 create mode 100644 sysdeps/riscv/rv32/nofpu/Implies
 create mode 100644 sysdeps/riscv/rv32/nofpu/libm-test-ulps
 create mode 100644 sysdeps/riscv/rv32/nofpu/libm-test-ulps-name
 create mode 100644 sysdeps/riscv/rv32/rvd/Implies
 create mode 100644 sysdeps/riscv/rv32/rvd/libm-test-ulps
 create mode 100644 sysdeps/riscv/rv32/rvd/libm-test-ulps-name
 create mode 100644 sysdeps/riscv/rv32/rvd/s_lrint.c
 create mode 100644 sysdeps/riscv/rv32/rvd/s_lround.c
 create mode 100644 sysdeps/riscv/rv32/rvf/Implies
 create mode 100644 sysdeps/riscv/rv32/rvf/s_lrintf.c
 create mode 100644 sysdeps/riscv/rv32/rvf/s_lroundf.c
 create mode 100644 sysdeps/riscv/rv64/nofpu/Implies
 create mode 100644 sysdeps/riscv/rv64/nofpu/libm-test-ulps
 create mode 100644 sysdeps/riscv/rv64/nofpu/libm-test-ulps-name
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/Implies
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/c++-types.data
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/jmp_buf-macros.h
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/ld.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libBrokenLocale.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libanl.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libc.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libcrypt.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libdl.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libm.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libnsl.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libpthread.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libresolv.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/librt.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libthread_db.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libutil.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/lockf64.c

-- 
2.7.4

Comments

Florian Weimer July 17, 2018, 10:19 a.m. | #1
* Zong Li:

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


Can this wait until the kernel interface has a 64-bit time_t?  I don't
think it makes sense to add entirely new 32-bit ABIs with a 32-bit
time_t at this point.
Joseph Myers July 17, 2018, 10:28 p.m. | #2
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
Zong Li July 18, 2018, 7:48 a.m. | #3
Florian Weimer <fw@deneb.enyo.de> 於 2018年7月17日 週二 下午6:19寫道:
>

> * Zong Li:

>

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

>

> Can this wait until the kernel interface has a 64-bit time_t?  I don't

> think it makes sense to add entirely new 32-bit ABIs with a 32-bit

> time_t at this point.


Hi Florian,

I know that seem to be a little insane, but whether we can add the
32-bit port first, and modify the
corresponding structure for all ports together at a time in glibc?
Zong Li July 18, 2018, 8:31 a.m. | #4
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
Joseph Myers July 18, 2018, 8:05 p.m. | #5
On Tue, 17 Jul 2018, Zong Li wrote:

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


>  sysdeps/riscv/nofpu/libm-test-ulps                 | 2198 --------------------


>  sysdeps/riscv/rv32/nofpu/libm-test-ulps            |  534 +++++


>  sysdeps/riscv/rv32/rvd/libm-test-ulps              | 1658 +++++++++++++++


>  sysdeps/riscv/rv64/nofpu/libm-test-ulps            | 2198 ++++++++++++++++++++


You should not need new libm-test-ulps files.  That you have them suggests 
to me some real problem with your libm port, until evidenced otherwise 
with a clear explanation of exactly how different results arise.  One file 
for hard float and one for soft float should fully suffice for all RISC-V.

The functions whose interface varies between 32-bit and 64-bit - those 
involving the "long" type as an argument or result - are also 
exactly-determined functions that should never have any ulps in their 
results.  There are a few dbl-64/wordsize-64 functions that are not 
exactly determined, but RV64 doesn't use dbl-64/wordsize-64 so that can't 
explain any differences.  Apart from that, everything not exactly 
determined should behave the same for RV32 and RV64 (including such things 
as the possibilities for fusing multiply and add).  Finally, both RV32 and 
RV64 use the same long double type, so that doesn't result in a difference 
as it does for MIPS32 versus MIPS64.

-- 
Joseph S. Myers
joseph@codesourcery.com
Joseph Myers July 18, 2018, 8:53 p.m. | #6
On Wed, 18 Jul 2018, Zong Li wrote:

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


What upstream kernel version *has a stable kernel/userspace ABI* for RV32 
and *is stable enough to run the glibc testsuite*?  I'd expect that to go 
in arch_minimum_kernel.

<https://sourceware.org/ml/libc-alpha/2018-07/msg00440.html> and 
<https://sourceware.org/ml/libc-alpha/2018-07/msg00447.html> appear to aim 
to remove legacy stat syscall families from new architectures, so 
requiring them to implement stat functions in terms of statx in userspace.  
The former, in particular, identifies RV32 as an architecture not needing 
backwards compatibility for the old syscalls.

Supposing those patches (that whole 17-patch series) are applied to the 
Linux kernel, what stat syscalls does it provide for RV32 (and RV64) and 
does your glibc port for RV32 properly work with that set of syscalls?

-- 
Joseph S. Myers
joseph@codesourcery.com
Palmer Dabbelt July 19, 2018, 5:18 p.m. | #7
On Mon, 16 Jul 2018 22:07:46 PDT (-0700), zong@andestech.com 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.

>

> There is a patch to fix the ld flags issue of tst-execstack-mod.so, it

> cause the fail on some test cases on RISC-V. In the v1 patch, I don't include

> this patch into patch set, in v2, I collect all patches together.

>

> There is a patch to add lack of implementation of 128 bit for soft-fp, these

> are necessary for building 32 bit RISC-V port.

>

> Thanks everyone for the help and Palmer's efforts during this work.


Sorry I've been a bit slow here, things have been very busy in embedded land 
for the last few months.  The good news is that we've now got a handful of 
software people at SiFive so I should be able to schedule a lot more time to do 
my due diligence on things like this as we move forward.

I should have time to dig through this over the weekend.

Thanks for the patches!

> Change in V2:

>  - Only include the ieee754/soft-fp path in rv32/nofpu/Implies.

>  - Add lack of implementation for 128 bit in soft-ft/op-8.h.

>  - Include the patch which fix the ld flags of tst-execstack-mod.so.

>  - Add the modification of URL of gcc's tarball.

>

> Zong Li (12):

>   Documentation for the 32 bit RISC-V port

>   RISC-V: Add dynamic loader for the 32 bit

>   RISC-V: Add path of library directories for the 32 bit

>   RISC-V: The ABI implementation for the 32-bit

>   RISC-V: Hard float support for the 32 bit

>   RISC-V: Split the soft-fp into rv32 and rv64

>   RISC-V: Add ABI lists

>   RISC-V: Build Infastructure for the 32 bit

>   Add 32 bit RISC-V to build-many-glibcs.py

>   soft-fp: Add the lack of implementation for 128 bit

>   Fix the ld flags not be applied to tst-execstack-mod.so

>   Change URL of gcc's tarball

>

>  NEWS                                               |    3 +

>  README                                             |    1 +

>  elf/Makefile                                       |    2 +-

>  scripts/build-many-glibcs.py                       |   17 +-

>  soft-fp/op-8.h                                     |  176 ++

>  sysdeps/riscv/bits/wordsize.h                      |    4 +-

>  sysdeps/riscv/nofpu/Implies                        |    1 -

>  sysdeps/riscv/nofpu/libm-test-ulps                 | 2198 --------------------

>  sysdeps/riscv/nofpu/libm-test-ulps-name            |    1 -

>  sysdeps/riscv/nptl/bits/pthreadtypes-arch.h        |   25 +-

>  sysdeps/riscv/preconfigure                         |    6 +-

>  sysdeps/riscv/rv32/Implies-after                   |    1 +

>  sysdeps/riscv/rv32/nofpu/Implies                   |    1 +

>  sysdeps/riscv/rv32/nofpu/libm-test-ulps            |  534 +++++

>  sysdeps/riscv/rv32/nofpu/libm-test-ulps-name       |    1 +

>  sysdeps/riscv/rv32/rvd/Implies                     |    3 +

>  sysdeps/riscv/rv32/rvd/libm-test-ulps              | 1658 +++++++++++++++

>  sysdeps/riscv/rv32/rvd/libm-test-ulps-name         |    1 +

>  sysdeps/riscv/rv32/rvd/s_lrint.c                   |   31 +

>  sysdeps/riscv/rv32/rvd/s_lround.c                  |   31 +

>  sysdeps/riscv/rv32/rvf/Implies                     |    1 +

>  sysdeps/riscv/rv32/rvf/s_lrintf.c                  |   31 +

>  sysdeps/riscv/rv32/rvf/s_lroundf.c                 |   31 +

>  sysdeps/riscv/rv64/nofpu/Implies                   |    1 +

>  sysdeps/riscv/rv64/nofpu/libm-test-ulps            | 2198 ++++++++++++++++++++

>  sysdeps/riscv/rv64/nofpu/libm-test-ulps-name       |    1 +

>  sysdeps/riscv/sfp-machine.h                        |   27 +-

>  sysdeps/riscv/sys/asm.h                            |    5 +-

>  sysdeps/unix/sysv/linux/riscv/Makefile             |    4 +-

>  sysdeps/unix/sysv/linux/riscv/configure            |   39 +

>  sysdeps/unix/sysv/linux/riscv/configure.ac         |    8 +

>  sysdeps/unix/sysv/linux/riscv/dl-cache.h           |   15 +-

>  sysdeps/unix/sysv/linux/riscv/ldconfig.h           |    2 +-

>  sysdeps/unix/sysv/linux/riscv/rv32/Implies         |    3 +

>  sysdeps/unix/sysv/linux/riscv/rv32/c++-types.data  |   67 +

>  .../unix/sysv/linux/riscv/rv32/jmp_buf-macros.h    |   53 +

>  sysdeps/unix/sysv/linux/riscv/rv32/ld.abilist      |    9 +

>  .../sysv/linux/riscv/rv32/libBrokenLocale.abilist  |    1 +

>  sysdeps/unix/sysv/linux/riscv/rv32/libanl.abilist  |    4 +

>  sysdeps/unix/sysv/linux/riscv/rv32/libc.abilist    | 2098 +++++++++++++++++++

>  .../unix/sysv/linux/riscv/rv32/libcrypt.abilist    |    7 +

>  sysdeps/unix/sysv/linux/riscv/rv32/libdl.abilist   |    9 +

>  sysdeps/unix/sysv/linux/riscv/rv32/libm.abilist    | 1021 +++++++++

>  sysdeps/unix/sysv/linux/riscv/rv32/libnsl.abilist  |  120 ++

>  .../unix/sysv/linux/riscv/rv32/libpthread.abilist  |  216 ++

>  .../unix/sysv/linux/riscv/rv32/libresolv.abilist   |   79 +

>  sysdeps/unix/sysv/linux/riscv/rv32/librt.abilist   |   35 +

>  .../sysv/linux/riscv/rv32/libthread_db.abilist     |   40 +

>  sysdeps/unix/sysv/linux/riscv/rv32/libutil.abilist |    6 +

>  sysdeps/unix/sysv/linux/riscv/rv32/lockf64.c       |   70 +

>  sysdeps/unix/sysv/linux/riscv/shlib-versions       |    4 +

>  51 files changed, 8686 insertions(+), 2214 deletions(-)

>  delete mode 100644 sysdeps/riscv/nofpu/Implies

>  delete mode 100644 sysdeps/riscv/nofpu/libm-test-ulps

>  delete mode 100644 sysdeps/riscv/nofpu/libm-test-ulps-name

>  create mode 100644 sysdeps/riscv/rv32/Implies-after

>  create mode 100644 sysdeps/riscv/rv32/nofpu/Implies

>  create mode 100644 sysdeps/riscv/rv32/nofpu/libm-test-ulps

>  create mode 100644 sysdeps/riscv/rv32/nofpu/libm-test-ulps-name

>  create mode 100644 sysdeps/riscv/rv32/rvd/Implies

>  create mode 100644 sysdeps/riscv/rv32/rvd/libm-test-ulps

>  create mode 100644 sysdeps/riscv/rv32/rvd/libm-test-ulps-name

>  create mode 100644 sysdeps/riscv/rv32/rvd/s_lrint.c

>  create mode 100644 sysdeps/riscv/rv32/rvd/s_lround.c

>  create mode 100644 sysdeps/riscv/rv32/rvf/Implies

>  create mode 100644 sysdeps/riscv/rv32/rvf/s_lrintf.c

>  create mode 100644 sysdeps/riscv/rv32/rvf/s_lroundf.c

>  create mode 100644 sysdeps/riscv/rv64/nofpu/Implies

>  create mode 100644 sysdeps/riscv/rv64/nofpu/libm-test-ulps

>  create mode 100644 sysdeps/riscv/rv64/nofpu/libm-test-ulps-name

>  create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/Implies

>  create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/c++-types.data

>  create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/jmp_buf-macros.h

>  create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/ld.abilist

>  create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libBrokenLocale.abilist

>  create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libanl.abilist

>  create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libc.abilist

>  create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libcrypt.abilist

>  create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libdl.abilist

>  create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libm.abilist

>  create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libnsl.abilist

>  create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libpthread.abilist

>  create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libresolv.abilist

>  create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/librt.abilist

>  create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libthread_db.abilist

>  create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libutil.abilist

>  create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/lockf64.c
Palmer Dabbelt July 24, 2018, 10:08 p.m. | #8
On Mon, 16 Jul 2018 22:07:46 PDT (-0700), zong@andestech.com 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.

>

> There is a patch to fix the ld flags issue of tst-execstack-mod.so, it

> cause the fail on some test cases on RISC-V. In the v1 patch, I don't include

> this patch into patch set, in v2, I collect all patches together.

>

> There is a patch to add lack of implementation of 128 bit for soft-fp, these

> are necessary for building 32 bit RISC-V port.

>

> Thanks everyone for the help and Palmer's efforts during this work.

>

> Change in V2:

>  - Only include the ieee754/soft-fp path in rv32/nofpu/Implies.

>  - Add lack of implementation for 128 bit in soft-ft/op-8.h.

>  - Include the patch which fix the ld flags of tst-execstack-mod.so.

>  - Add the modification of URL of gcc's tarball.

>

> Zong Li (12):

>   Documentation for the 32 bit RISC-V port

>   RISC-V: Add dynamic loader for the 32 bit

>   RISC-V: Add path of library directories for the 32 bit

>   RISC-V: The ABI implementation for the 32-bit

>   RISC-V: Hard float support for the 32 bit

>   RISC-V: Split the soft-fp into rv32 and rv64

>   RISC-V: Add ABI lists

>   RISC-V: Build Infastructure for the 32 bit

>   Add 32 bit RISC-V to build-many-glibcs.py

>   soft-fp: Add the lack of implementation for 128 bit

>   Fix the ld flags not be applied to tst-execstack-mod.so

>   Change URL of gcc's tarball


Thanks for doing this Zong.  I don't think there's anything major in the patch 
set, the bigger issues are externally.  As it's been pointed out, the Linux ABI 
is still a bit mushy and I don't there's nearly enough time to get everything 
in shape for the glibc release, which if I understand correctly is still 
targeted for early in August.

I think we should focus on ensuring this release is sane in RV64 land, and then 
add the RV32 port after the release so it has a whole cycle to calm down.

Thanks for doing all this work.  If you'd like I can take the patches from 
here and deal with things like cleaning up the Linux ABI and the test suites, 
but if you have time then feel free.

Thanks, again!
Zong Li July 25, 2018, 3:19 p.m. | #9
Palmer Dabbelt <palmer@dabbelt.com> 於 2018年7月25日 週三 上午6:08寫道:
>

> On Mon, 16 Jul 2018 22:07:46 PDT (-0700), zong@andestech.com 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.

> >

> > There is a patch to fix the ld flags issue of tst-execstack-mod.so, it

> > cause the fail on some test cases on RISC-V. In the v1 patch, I don't include

> > this patch into patch set, in v2, I collect all patches together.

> >

> > There is a patch to add lack of implementation of 128 bit for soft-fp, these

> > are necessary for building 32 bit RISC-V port.

> >

> > Thanks everyone for the help and Palmer's efforts during this work.

> >

> > Change in V2:

> >  - Only include the ieee754/soft-fp path in rv32/nofpu/Implies.

> >  - Add lack of implementation for 128 bit in soft-ft/op-8.h.

> >  - Include the patch which fix the ld flags of tst-execstack-mod.so.

> >  - Add the modification of URL of gcc's tarball.

> >

> > Zong Li (12):

> >   Documentation for the 32 bit RISC-V port

> >   RISC-V: Add dynamic loader for the 32 bit

> >   RISC-V: Add path of library directories for the 32 bit

> >   RISC-V: The ABI implementation for the 32-bit

> >   RISC-V: Hard float support for the 32 bit

> >   RISC-V: Split the soft-fp into rv32 and rv64

> >   RISC-V: Add ABI lists

> >   RISC-V: Build Infastructure for the 32 bit

> >   Add 32 bit RISC-V to build-many-glibcs.py

> >   soft-fp: Add the lack of implementation for 128 bit

> >   Fix the ld flags not be applied to tst-execstack-mod.so

> >   Change URL of gcc's tarball

>

> Thanks for doing this Zong.  I don't think there's anything major in the patch

> set, the bigger issues are externally.  As it's been pointed out, the Linux ABI

> is still a bit mushy and I don't there's nearly enough time to get everything

> in shape for the glibc release, which if I understand correctly is still

> targeted for early in August.

>

> I think we should focus on ensuring this release is sane in RV64 land, and then

> add the RV32 port after the release so it has a whole cycle to calm down.

>

> Thanks for doing all this work.  If you'd like I can take the patches from

> here and deal with things like cleaning up the Linux ABI and the test suites,

> but if you have time then feel free.

>

> Thanks, again!


OK, maybe I can submit the version three to fix up the known issue in
version two
before you clean up ABI and test suites? or some way let you can get
the modification
if submitting the version three is inappropriate, or you want to take
version two patches.
How do you think?

As the cover letter mention, there are math fail cases need to be
clarified, I will
keep to track and get you feedback when I get the point about that.

There is a patch about lack of implementation for 128 soft-fp. On the
Joseph recommend,
it should be out of the patch set, so I will submit it separately.

Thanks Joseph, Palmer, DJ and  Richard's help and review the patches.
Palmer Dabbelt July 25, 2018, 3:21 p.m. | #10
On Wed, 25 Jul 2018 08:19:51 PDT (-0700), zongbox@gmail.com wrote:
> Palmer Dabbelt <palmer@dabbelt.com> 於 2018年7月25日 週三 上午6:08寫道:

>>

>> On Mon, 16 Jul 2018 22:07:46 PDT (-0700), zong@andestech.com 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.

>> >

>> > There is a patch to fix the ld flags issue of tst-execstack-mod.so, it

>> > cause the fail on some test cases on RISC-V. In the v1 patch, I don't include

>> > this patch into patch set, in v2, I collect all patches together.

>> >

>> > There is a patch to add lack of implementation of 128 bit for soft-fp, these

>> > are necessary for building 32 bit RISC-V port.

>> >

>> > Thanks everyone for the help and Palmer's efforts during this work.

>> >

>> > Change in V2:

>> >  - Only include the ieee754/soft-fp path in rv32/nofpu/Implies.

>> >  - Add lack of implementation for 128 bit in soft-ft/op-8.h.

>> >  - Include the patch which fix the ld flags of tst-execstack-mod.so.

>> >  - Add the modification of URL of gcc's tarball.

>> >

>> > Zong Li (12):

>> >   Documentation for the 32 bit RISC-V port

>> >   RISC-V: Add dynamic loader for the 32 bit

>> >   RISC-V: Add path of library directories for the 32 bit

>> >   RISC-V: The ABI implementation for the 32-bit

>> >   RISC-V: Hard float support for the 32 bit

>> >   RISC-V: Split the soft-fp into rv32 and rv64

>> >   RISC-V: Add ABI lists

>> >   RISC-V: Build Infastructure for the 32 bit

>> >   Add 32 bit RISC-V to build-many-glibcs.py

>> >   soft-fp: Add the lack of implementation for 128 bit

>> >   Fix the ld flags not be applied to tst-execstack-mod.so

>> >   Change URL of gcc's tarball

>>

>> Thanks for doing this Zong.  I don't think there's anything major in the patch

>> set, the bigger issues are externally.  As it's been pointed out, the Linux ABI

>> is still a bit mushy and I don't there's nearly enough time to get everything

>> in shape for the glibc release, which if I understand correctly is still

>> targeted for early in August.

>>

>> I think we should focus on ensuring this release is sane in RV64 land, and then

>> add the RV32 port after the release so it has a whole cycle to calm down.

>>

>> Thanks for doing all this work.  If you'd like I can take the patches from

>> here and deal with things like cleaning up the Linux ABI and the test suites,

>> but if you have time then feel free.

>>

>> Thanks, again!

>

> OK, maybe I can submit the version three to fix up the known issue in

> version two

> before you clean up ABI and test suites? or some way let you can get

> the modification

> if submitting the version three is inappropriate, or you want to take

> version two patches.

> How do you think?


Submitting a v3 would be great, thanks!

> As the cover letter mention, there are math fail cases need to be

> clarified, I will

> keep to track and get you feedback when I get the point about that.

>

> There is a patch about lack of implementation for 128 soft-fp. On the

> Joseph recommend,

> it should be out of the patch set, so I will submit it separately.


Makes sense.

> Thanks Joseph, Palmer, DJ and  Richard's help and review the patches.


Well, thanks for doing the work :)