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

[Vincent Chen <vincentc at andestech dot com>]

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