Message ID | cover.1531801545.git.zong@andestech.com |
---|---|
Headers | show |
Series | RISC-V glibc port for the 32 bit | expand |
* 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.
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.
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?
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
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.
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?
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
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!
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.
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 :)