Message ID | 1559735815-20093-1-git-send-email-vincentc@andestech.com |
---|---|
Headers | show |
Series | nds32 glibc port, v4 | expand |
* Vincent Chen: > 7. misc/tst-syscall-list > This case turns to PASS if I add NR_fp_udfiex_crtl to > linux/syscall-names.list I think the actual system call name is fp_udfiex_crtl, and this can go in immediately as a separate patch (it's not necessary to wait for the upstream kernel release). Thanks, Florian
On Wed, Jun 05, 2019 at 08:28:15PM +0800, Florian Weimer wrote: > * Vincent Chen: > > > 7. misc/tst-syscall-list > > This case turns to PASS if I add NR_fp_udfiex_crtl to > > linux/syscall-names.list > > I think the actual system call name is fp_udfiex_crtl, and this can go > in immediately as a separate patch (it's not necessary to wait for the > upstream kernel release). > Yes, the actual system call name is fp_udfiex_crtl. I will use a separate patch to complete it in the next version patchset. Thanks, Vincent
On Wed, 5 Jun 2019, Vincent Chen wrote: > This is the fourth version of the nds32 port. I am sorry that one year has > passed since the previous submission. The most obvious modification in this > version patchset is that FPU extension is supported now.In addition, > the mainline of gcc and binutils has contained the nds32 ports.Hence, the > nds32 toolchain without FPU extension support can be derived through > build-many-glibcs.py. The toolchain with FPU extension needs an extra kernel > patchset to successfully compile. This patchset has been pulled and may be > released in 5.2 rc-4. The implementations for nds32 FPU extension are like > other architecture except for the following two parts. Please see <https://sourceware.org/glibc/wiki/NewPorts> and make sure the port submission follows what is described there. In particular: (a) give pointers to the relevant instruction set and ABI manuals (<https://gcc.gnu.org/readings.html> points to a page with a great many manuals, pointers directly to exactly the ones that are relevant would be helpful); (b) fix coding style issues, such as brace positioning, indentation and missing spaces before '('. > B. The analysis of FAIL cases: > 1. The following 20 cases have same error behevior, namespace violation: > "SIOCGSTAMP_OLD", "SIOCGSTAMPNSD", "fds_bits" and "val". The cause of > the first two cases, "SIOCGSTAMP_OLD" and "SIOCGSTAMPNSD", is the same > that Linux kernel recently added the definition of these two macros in > asm-generic/sockios.h. For the last two cases, kernel header > uapi/asm-generic/socket.h includes linux/posix_types.h instead of > asm/bitsperlong.h. This change introduces the two variables "fds_bits" > and "val" declared in the linux/posix_types.h and > asm-generic/posix_types.h. fds_bits and val are a generic Linux kernel issue - a patch was sent to linux-api in March and acked by David Miller but still didn't get into the Linux kernel in 5.1 (and, indeed, still hasn't got into the kernel). I'm not sure what the holdup is there, but for now we should assume that Linux kernel header versions later than 5.0 are not suitable for use in glibc (and so probably avoid adding any new ports depending on newer kernel header versions, because of the possibility of being unable to test them effectively for an indefinite period while build-many-glibcs.py is stuck on 5.0). The others also sound like a generic issue. Please *start a separate thread on them, not part of the port submission*. Is this like the case where sysdeps/unix/sysv/linux/bits/socket.h has /* Ugly workaround for unclean kernel headers. */ for some existing macros? If so, you should send a patch for that, extending the workaround to the new macros (again, not part of the port submission, not marked as part of the port submission, because it's an independent issue). > 2. locale/tst-locale-locpath > I found that the failure is caused by missing the environment parameter > when this testcase is executed on FPGA through cross-test-ssh.sh. I try > to modify the Makefile rule of tst-locale-locpath.out to "$(SHELL) $< > '$(common-objpfx)' '$(test-wrapper-env)' '$(run_program_env)' > $ @;" > .However, the content of $ (run_program_env) is empty so that the > environment parameter is still empty. > The testcase passed if I set the environment parameters by manually. Again, start an independent thread on this issue. I'm not sure if $(run_program_env) should be passed at all (given how this test is deliberately overriding the default environment), but in any case, the call in the Makefile should be consistent with the test script - and this needs to be discussed outside the context of a port submission. > 3. libio/tst-wfile-sync.test-result > The testcases will try to operate the standard input file by lseek > function. However, the standard input is pipe instead of file if this > testcase run on FPGA through cross-test-ssh.sh. This causes testcase gets > an unexpected error ESPIPE from the return of the lseek function. > The testcase passed if it was directly executed on FPGA board. Likewise, start a separate thread, not marked as part of a port submission, for any such architecture-independent issue; resolve such issues first and ensure the port submission only needs to include genuinely architecture-specific patches. > I tried to port the latest soft-fp module from glibc to kernel, and the > above 21 failed testcases turned into PASS based on the latest soft-fp > module. By the way, I found that Joseph tried to update the soft-fp > module in Linux kernel in 2015, but the last status of the patchset seems > to remain pending due to the lack of ACK from sparc maintainer. Does > Joseph have any plans to resend the patchset? No. It was accepted by the powerpc maintainers into a branch with a statement "I'll ask Stephen to put it in linux-next once 4.3-rc1 is out, and I'll ask Linus to pull it for 4.4". I don't know what the holdup is that stopped it going further. There was an issue with sparc compilers that didn't default to -mlong-double-128, but a patch for that was added in Nov 2015. There was a build robot reporting new warnings on sh but I didn't think they indicated any actual problems that were new with the patch (which was acked for sh). Since that patch series deals with the hard part of an update (i.e. updating the kernel code across several architectures for extensive API changes in glibc soft-fp made as part of the optimization project described in the GCC Summit 2006 proceedings, and subsequently), I think it makes sense to integrate that patch series more or less as I posted it (plus, I suppose, a corresponding nds32 patch), and then possibly follow up with another update of the code to the latest glibc version (much easier because of the lack of API changes needing all-architectures fixes). Note: I have a long list of issues with the powerpc math emulation in the Linux kernel (i.e., the architecture-specific code) that could reasonably be fixed after that series is in, and shorter lists for alpha and sh (all of those are lists as of 2015, I don't know if some of the issues might have been fixed in the kernel since then). > 7. misc/tst-syscall-list > This case turns to PASS if I add NR_fp_udfiex_crtl to > linux/syscall-names.list Again, send a separate patch outside of this series. > 8. The following 6 testcase fail because the testing environment lacks > native python: > ./nptl/test-condattr-printers > ./nptl/test-cond-printers > ./nptl/test-mutexattr-printers > ./nptl/test-mutex-printers > ./nptl/test-rwlockattr-printers > ./nptl/test-rwlock-printers > > 9. stdio-common/bug22 > The required memory size for this testcase is more than 2 GB but > the DRAM size on our FPGA is just 2GB. Therefore, the errno is set as > ENOMEM instead of EOVERFLOW. > > 10. bug20790.test-result > It fails because the testing environment lacks native cpp These are on the list of known architecture-independent issues on the per-release wiki pages, thus can be ignored for the purposes of the expectation of no more than 20 architecture-specific test failures.
* Vincent Chen: > On Wed, Jun 05, 2019 at 08:28:15PM +0800, Florian Weimer wrote: >> * Vincent Chen: >> >> > 7. misc/tst-syscall-list >> > This case turns to PASS if I add NR_fp_udfiex_crtl to >> > linux/syscall-names.list >> >> I think the actual system call name is fp_udfiex_crtl, and this can go >> in immediately as a separate patch (it's not necessary to wait for the >> upstream kernel release). > Yes, the actual system call name is fp_udfiex_crtl. I will use a > separate patch to complete it in the next version patchset. You can submit this change separately any time, it is not tied to the port. Thanks, Florian
On Fri, Jun 07, 2019 at 03:17:58PM +0800, Florian Weimer wrote: > * Vincent Chen: > > > On Wed, Jun 05, 2019 at 08:28:15PM +0800, Florian Weimer wrote: > >> * Vincent Chen: > >> > >> > 7. misc/tst-syscall-list > >> > This case turns to PASS if I add NR_fp_udfiex_crtl to > >> > linux/syscall-names.list > >> > >> I think the actual system call name is fp_udfiex_crtl, and this can go > >> in immediately as a separate patch (it's not necessary to wait for the > >> upstream kernel release). > > > Yes, the actual system call name is fp_udfiex_crtl. I will use a > > separate patch to complete it in the next version patchset. > > You can submit this change separately any time, it is not tied to the > port. > Ok, I got it. Thank you. Regards, vincent
On Fri, Jun 07, 2019 at 06:34:47AM +0800, Joseph Myers wrote: > On Wed, 5 Jun 2019, Vincent Chen wrote: > > > Please see <https://sourceware.org/glibc/wiki/NewPorts> and make sure the > port submission follows what is described there. In particular: (a) give > pointers to the relevant instruction set and ABI manuals > (<https://gcc.gnu.org/readings.html> points to a page with a great many > manuals, pointers directly to exactly the ones that are relevant would be > helpful); (b) fix coding style issues, such as brace positioning, > indentation and missing spaces before '('. > Ok > > fds_bits and val are a generic Linux kernel issue - a patch was sent to > linux-api in March and acked by David Miller but still didn't get into the > Linux kernel in 5.1 (and, indeed, still hasn't got into the kernel). I'm > not sure what the holdup is there, but for now we should assume that Linux > kernel header versions later than 5.0 are not suitable for use in glibc > (and so probably avoid adding any new ports depending on newer kernel > header versions, because of the possibility of being unable to test them > effectively for an indefinite period while build-many-glibcs.py is stuck > on 5.0). > Ok, I will develop nds32 ports based on kernel 5.0 before relevant issues are fixed in kernel. > The others also sound like a generic issue. Please *start a separate > thread on them, not part of the port submission*. Is this like the case > where sysdeps/unix/sysv/linux/bits/socket.h has > > /* Ugly workaround for unclean kernel headers. */ > > for some existing macros? If so, you should send a patch for that, > extending the workaround to the new macros (again, not part of the port > submission, not marked as part of the port submission, because it's an > independent issue). > Yes, the issue of the macros "SIOCGSTAMPNS_OLD" and "SIOCGSTAMP_OLD" is similar to the case in sysdeps/unix/sysv/linux/bits/socket.h. I will send a separate patch to add these two macros to the workaround list. > > 2. locale/tst-locale-locpath > > Again, start an independent thread on this issue. I'm not sure if > $(run_program_env) should be passed at all (given how this test is > deliberately overriding the default environment), but in any case, the > call in the Makefile should be consistent with the test script - and this > needs to be discussed outside the context of a port submission. > Ok > > 3. libio/tst-wfile-sync.test-result > > Likewise, start a separate thread, not marked as part of a port > submission, for any such architecture-independent issue; resolve such > issues first and ensure the port submission only needs to include > genuinely architecture-specific patches. > Ok > > to remain pending due to the lack of ACK from sparc maintainer. Does > > Joseph have any plans to resend the patchset? > > No. It was accepted by the powerpc maintainers into a branch with a > statement "I'll ask Stephen to put it in linux-next once 4.3-rc1 is out, > and I'll ask Linus to pull it for 4.4". I don't know what the holdup is > that stopped it going further. There was an issue with sparc compilers > that didn't default to -mlong-double-128, but a patch for that was added > in Nov 2015. There was a build robot reporting new warnings on sh but I > didn't think they indicated any actual problems that were new with the > patch (which was acked for sh). > > Since that patch series deals with the hard part of an update (i.e. > updating the kernel code across several architectures for extensive API > changes in glibc soft-fp made as part of the optimization project > described in the GCC Summit 2006 proceedings, and subsequently), I think > it makes sense to integrate that patch series more or less as I posted it > (plus, I suppose, a corresponding nds32 patch), and then possibly follow > up with another update of the code to the latest glibc version (much > easier because of the lack of API changes needing all-architectures > fixes). > > Note: I have a long list of issues with the powerpc math emulation in the > Linux kernel (i.e., the architecture-specific code) that could reasonably > be fixed after that series is in, and shorter lists for alpha and sh (all > of those are lists as of 2015, I don't know if some of the issues might > have been fixed in the kernel since then). > I got it. Thank you very much for the detailed descriptions. > > 7. misc/tst-syscall-list > > This case turns to PASS if I add NR_fp_udfiex_crtl to > > linux/syscall-names.list > > Again, send a separate patch outside of this series. > Ok Regards, Vincent