Re: [PATCH v4 00/11] nds32 glibc port, v4

[Joseph Myers <joseph at codesourcery dot com>]

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.

-- 
Joseph S. Myers
joseph@codesourcery.com