Re: [RFC PATCH V2 00/10] port C-SKY to glibc

[Joseph Myers <joseph at codesourcery dot com>]

This message didn't reach the libc-alpha list because of the large 
attachments.  There's a message size limit (a few hundred kB?); the 
detailed test logs need to go somewhere external to which you include the 
URL when sending the next port version (the list of FAILs and summary of 
results should still be included directly in the message to libc-alpha).

On Thu, 26 Apr 2018, Mao Han wrote:

> Got two fail on build check, elf/check-textrel seems caused by our gcc
> tools. elf/check-localplt says matherr is missing as 
> # define LIBM_SVID_COMPAT SHLIB_COMPAT (libm, GLIBC_2_0, GLIBC_2_27)
> and I use GLIBC_2_28. 135 fails in math, and 64 others. I haven't

You need to add a localplt.data file, like for RISC-V.

> The hard-float result is much worse. Got 1.8k fails in math. Seems 
> most of them are precision problems.

First try truncating your libm-test-ulps file and regenerating with "make 
regen-ulps", to make sure it's up to date with current sources and tests.

> > Since all the ABIv1 support is being removed as part of preparing the GCC 
> > port for upstream, that means no ABIv1 support should be included anywhere 
> > in the glibc port.  It's OK to have #if or similar conditionals with 
> > #error in the ABIv1 case, but not anything more than errors for ABIv1.  
> > This is exactly analogous to the case of 32-bit RISC-V: because the kernel 
> > support for 32-bit RISC-V was not ready when the glibc port went in, all 
> > such support was removed in the glibc port or turned into #errors.  If in 
> > future the kernel support for 32-bit RISC-V is good enough to run the 
> > glibc testsuite with reasonable results, glibc support can be added at 
> > that point (and much the same would apply if ABIv1 support were added to 
> > GCC for C-SKY in future - of course, for upstream it would need to be 
> > cleanly implemented with appropriate -m options for selecting the ABI).
> > 
> As ABIv1 is widely used by our customers ,and included in our linux kernel
> upstream. I need to keep working on a port with ABIv1 and ABIv2. I will
> remove the ABIv1 part next time I send the patch.

Obviously you can have your own branch that adds ABIv1 support - but the 
presumption is it only goes upstream if and when the binutils / GCC 
support is upstream, and has the symbol version of the next glibc release 
at that time (just as if 32-bit RISC-V support goes into glibc, it will 
have GLIBC_2.28 or later minimum symbol version, not the GLIBC_2.27 
version used for 64-bit RISC-V).

-- 
Joseph S. Myers
joseph@codesourcery.com