| Message ID | cover.1523169833.git.han_mao@c-sky.com |
|---|---|
| Headers | show |
| Series | port C-SKY to glibc | expand |
* Mao Han: > CK610 is the second-generation CPU of CSKY, fullycompatible with M*Core. > CK807/CK810 bases on C-SKY V2 instruction set architecture and 16/32-bit > variable length instruction. Including basic core(CK807/CK810), > floating-point enhancement(CK807F/CK810F), multimedia enhancement (CK810D) > and multiple-processing extension (CK807MP/CK810MP). Which ABIs of those do you intend to support? These should be added to the README file.
On Sun, Apr 08, 2018 at 09:50:16AM +0200, Florian Weimer wrote: Hi, > * Mao Han: > > > CK610 is the second-generation CPU of CSKY, fullycompatible with M*Core. > > CK807/CK810 bases on C-SKY V2 instruction set architecture and 16/32-bit > > variable length instruction. Including basic core(CK807/CK810), > > floating-point enhancement(CK807F/CK810F), multimedia enhancement (CK810D) > > and multiple-processing extension (CK807MP/CK810MP). > > Which ABIs of those do you intend to support? > > These should be added to the README file. Thanks for comment. In glibc and linux we only cares about following cpu and extensions. ck610 only have: ck610 ck807 could have: ck807 ck807f ck807vf ck807ef ck810 could have: ck810 ck810f ck810vf ck810ef ck860 could have: ck860 ck860f ck860vf f: means FPU co-processor v: means VDSP co-processor just like "ARM-NEON" e: is our old DSP co-processor which use HI-LO regs for operation. In current ck807/ck810 they default have HI-LO regs. For this patch-set, we support: ck610 (ck807/ck807f/ck807ef) (ck810/ck810e/ck810ef) ck6** use csky-*-linux-gnuabiv1, ck8** use csky-*-linux-gnuabiv2 I will update the introduction for these. It seems only this need be added to the README file. Is that correct? csky-*-linux-gnuabi Best Regards Mao Han
On 04/08/2018 10:29 AM, Mao Han wrote: > On Sun, Apr 08, 2018 at 09:50:16AM +0200, Florian Weimer wrote: > Hi, >> * Mao Han: >> >>> CK610 is the second-generation CPU of CSKY, fullycompatible with M*Core. >>> CK807/CK810 bases on C-SKY V2 instruction set architecture and 16/32-bit >>> variable length instruction. Including basic core(CK807/CK810), >>> floating-point enhancement(CK807F/CK810F), multimedia enhancement (CK810D) >>> and multiple-processing extension (CK807MP/CK810MP). >> >> Which ABIs of those do you intend to support? >> >> These should be added to the README file. > > Thanks for comment. > In glibc and linux we only cares about following cpu and extensions. > > ck610 only have: ck610 > ck807 could have: ck807 ck807f ck807vf ck807ef > ck810 could have: ck810 ck810f ck810vf ck810ef > ck860 could have: ck860 ck860f ck860vf > f: means FPU co-processor > v: means VDSP co-processor just like "ARM-NEON" > e: is our old DSP co-processor which use HI-LO regs for operation. In > current ck807/ck810 they default have HI-LO regs. > > For this patch-set, we support: > ck610 > (ck807/ck807f/ck807ef) > (ck810/ck810e/ck810ef) > > ck6** use csky-*-linux-gnuabiv1, ck8** use csky-*-linux-gnuabiv2 > I will update the introduction for these. > > It seems only this need be added to the README file. Is that correct? > csky-*-linux-gnuabi It's still not clear to me whether you intend to support more than one ABI (there is a __CSKYABIV2__ preprocessor conditional in the submission, for example). If you support multiple ABIs, won't you need different target triplets? Thanks, Florian
Hi, > It's still not clear to me whether you intend to support more than one ABI > (there is a __CSKYABIV2__ preprocessor conditional in the submission, for > example). > > If you support multiple ABIs, won't you need different target triplets? > Two ABIs are supported. csky abiv1 and csky abiv2. In target triplets it is distinguish by the ABI section in csky-vendor-linux-libc[ABI]. Best Regards Mao Han
When maintaining or submitting a new glibc port, it is strongly advisable
to read recent reviews of other glibc ports, because there are many issues
relating to current good practice in glibc ports that are relevant to any
new port submission, and so by studying the past reviews you can avoid
your port suffering from the same problems as the previous ports. Thus,
you should read all the reviews in the past year or so of the ARC port and
of many versions of the RISC-V port, and address the issues in the next
version of this port, where relevant to it.
In addition, it is important when maintaining a port out of tree to ensure
that you keep monitoring global glibc changes made across ports and keep
your port up to date for such global changes. Such fixes to update the
port for such global changes are an important part of the work Sandra has
done to prepare the binutils and GCC ports for upstream submission.
The following are a very non-exhaustive list of such generic issues that I
believe are applicable to this port. I expect there are others that can
be found by a more detailed study of the ARC and RISC-V reviews.
1. Any glibc port submission needs to include the results of running the
glibc testsuite, for all the main supported configurations of the port.
This means the full testsuite, both compilation and execution tests. It
may be run natively, or you may use cross testing using test-wrapper.
The final part of the "make check" output, listing all non-PASS/XFAIL
tests and statistics of different test results, needs to be included in
the port submission. It's desirable to provide a tarball of .out /
.test-result files for all such tests, and the full "make check" output,
somewhere external from where people can download it to study the results
in more detail - but the basic summary, for each of the main supported
configurations, needs to be included in the port submission.
Furthermore, the results that are relevant are, as I said in ARC port
discussions, results with *upstream* versions of the other components, not
some version that may be on GitHub or elsewhere. That means upstream
Linux, binutils, GCC - or, until the ports are upstream, the latest
versions submitted upstream or being prepared for upstream.
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).
Furthermore, for a glibc port to be considered in a reasonable state for
upstream, we expect no more than about 20 architecture-specific failures
(you can disregard generic cross-testing failures such as listed at
<https://sourceware.org/glibc/wiki/Release/2.27>).
2. Any glibc port needs to add appropriate configurations to
build-many-glibcs.py. These should cover all the different ABIs supported
by the port, and any other significant variations. When using the latest
upstream versions of all components, these configurations must pass
compilers / glibcs builds - there must be no compilation test failures for
the new configurations whatever.
I don't believe the present port would pass the compilation parts of the
testsuite. For example, your sys/ucontext.h headers include headers they
should not include and define names that are not permitted to be defined,
without any __USE_MISC etc. conditionals as in other such headers. (This
is also an example of something that would have shown up in monitoring
global glibc changes to keep your port up to date with them.)
3. The minimum symbol version needs to be GLIBC_2.28 at present. If the
kernel port isn't upstream in the next few months, then the glibc port
can't go upstream in that time either, so you'll need a corresponding
later minimum symbol version.
4. arch_minimum_kernel has to reflect the kernel version in which the
support goes upstream. That's certainly not 2.6.25. Since the support
didn't get into 4.17-rc1, presumably it needs to be 4.18.0 or later, and
to keep being updated until the kernel support is upstream.
5. New ports should have ABI-specific dynamic linker names - a different
name for each supported ABI variant, different from those used on all
other architectures, to support systems using multi-arch directory
arrangements. For example, ld-linux-csky-{be,le}.so.1 (since you seem to
support both endiannesses) might be appropriate, but not ld.so.1 which you
currently have in shlib-versions (and not ld-linux.so.2 which you
currently have in a bogus entry in ldconfig.h). If there are other
relevant ABI variants beyond endianness, those should be allowed for in
the dynamic linker names. You should give a more detailed explanation of
what variants are or are not ABI compatible to justify the particular
choice of what gets a separate dynamic linker name.
This of course needs coordinating with the GCC port so it passes
appropriate -dynamic-linker options to ld.
6. Many files are missing the one-line description on the first line of
the file before the copyright notice.
The following are more specific to this port:
7. There should be no abiv2_* files. If ABIv1 were supported, the sysdeps
mechanism would need to be used with abiv1/ and abiv2/ subdirectories to
select appropriate files.
8. You have *_vfp* function names and references to VFP in comments. Is
VFP really the name of the floating-point unit for this architecture? If
not, this is cargo-culted from ARM and needs to be fixed (likewise, the
comments in math-tests.h may not be correct for this architecture).
9. You have __csky_hard_float__ conditionals in sysdeps/csky/fpu/ files.
That makes no sense. If you have a proper with_fp_cond setting (see about
monitoring global changes, again), then fpu/ files shouldn't be used at
all for soft float. That means you can remove those conditionals and just
rely on the default math/ fallback implementations of fenv.h functions.
Such conditionals are still relevant in *installed* headers, but not in
fpu/ files.
10. Existing practice in glibc is that where you have e.g. FE_DENORMAL,
such architecture-specific values are only defined in the implementation
namespace (e.g. __FE_DENORM in sysdeps/x86/fpu/bits/fenv.h) and are *not*
included in FE_ALL_EXCEPT.
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).