Message ID | cover.1536715883.git.han_mao@c-sky.com |
---|---|
Headers | show |
Series | port C-SKY to glibc | expand |
On Wed, 12 Sep 2018, Mao Han wrote: > 38245425a9add7bd22f8732219e0085432f223b6 (6 sep). Two abi combinations > are supported with this patch: C-SKY ABIV2 with (soft float & little endian, > hard float & little endian). CK807(ef), CK810(ef), CK860 are the Could you please clarify whether those are the same ABI (compatible for function calling, structure layout for types from glibc headers, etc.) or different ABIs? If they are different ABIs, they should have different dynamic linker names (of course you need to make the GCC port reflect the dynamic linker name used for each ABI), and your bits/fenv.h should disable most of its contents for soft float, like e.g. MIPS does (define only __FE_UNDEFINED and FE_TONEAREST as rounding modes in that case, define FE_ALL_EXCEPT to 0 and no other exception macros, do not define FE_NOMASK_ENV). Then you shouldn't need math-tests-exceptions.h and math-tests-rounding.h in the nofpu directory because things will be handled automatically when bits/fenv.h avoids defining unsupported things. If they are the same ABI, I don't see any use for the CSKY_HARD_FLOAT macro defined in preconfigure; nothing seems to test it, so it's only relevant if shlib-versions is testing it (i.e. if they are different ABIs with different dynamic linker names). Does C-SKY hard float support exception traps or not? math-tests-trap.h has a comment saying not. But you have an implementation of feenableexcept that implies it does support exception traps. * If exception traps are never supported, everything related to them (including the definition of FE_NOMASK_ENV) should be removed; the default feenableexcept and fedisableexcept and fegetexcept implementations should suffice. * If exception traps are always supported, your math-tests-trap.h is wrong and should be removed. * If they are conditionally supported, like on Arm and AArch64, your math-tests-trap.h is appropriate with a different comment explaining the conditional support - but various fenv.h functions like feenableexcept need to check for the support and give errors if asked to enable exception traps they are unable to enable (this includes fesetenv and feupdateenv passed FE_NOMASK_ENV - see Arm and AArch64 for examples). > Several patches will be post to GCC and Binutils to fix some testcase fail > later this month, while the follow results have these patches applied. Note that glibc ports can't go in while they depend on such non-upstream patches for good results (see the ARC port discussion). You can send a list of all the patches required to get the given test results, but they'll need to be upstream (as will the Linux kernel port) before the port can go into glibc. > 5. The following cases fail due to gcc optimize change the sequence of > -a * b to -(a * b) and got 1ulps error. > math/test-double-tgamma > math/test-float-tgamma > math/test-float32-tgamma > math/test-float32x-tgamma > math/test-float64-tgamma > math/test-ldouble-tgamma So that needs a GCC bug fix (just like when the Arm and AArch64 ports of GCC used to have such a bug).
On Wed, Sep 12, 2018 at 12:31:24PM +0000, Joseph Myers wrote: > On Wed, 12 Sep 2018, Mao Han wrote: > > > 38245425a9add7bd22f8732219e0085432f223b6 (6 sep). Two abi combinations > > are supported with this patch: C-SKY ABIV2 with (soft float & little endian, > > hard float & little endian). CK807(ef), CK810(ef), CK860 are the > > Could you please clarify whether those are the same ABI (compatible for > function calling, structure layout for types from glibc headers, etc.) or > different ABIs? > > If they are different ABIs, they should have different dynamic linker > names (of course you need to make the GCC port reflect the dynamic linker > name used for each ABI), and your bits/fenv.h should disable most of its > contents for soft float, like e.g. MIPS does (define only __FE_UNDEFINED > and FE_TONEAREST as rounding modes in that case, define FE_ALL_EXCEPT to 0 > and no other exception macros, do not define FE_NOMASK_ENV). Then you > shouldn't need math-tests-exceptions.h and math-tests-rounding.h in the > nofpu directory because things will be handled automatically when > bits/fenv.h avoids defining unsupported things. > > If they are the same ABI, I don't see any use for the CSKY_HARD_FLOAT > macro defined in preconfigure; nothing seems to test it, so it's only > relevant if shlib-versions is testing it (i.e. if they are different ABIs > with different dynamic linker names). Hard float will use to vr to pass arguments, the ABI is imcompatible if the function has any float-point arguments. I use the same dynamic linker names because there is no float in ldso, the same ldso can be used on system with soft float/hard float. Seems I still need to use different dynamic linker names even if they are compatible, and distinct soft float/hard float in bits/fenv.h to make glibc have correct definitions? > > Does C-SKY hard float support exception traps or not? math-tests-trap.h > has a comment saying not. But you have an implementation of > feenableexcept that implies it does support exception traps. > > * If exception traps are never supported, everything related to them > (including the definition of FE_NOMASK_ENV) should be removed; the default > feenableexcept and fedisableexcept and fegetexcept implementations should > suffice. > > * If exception traps are always supported, your math-tests-trap.h is wrong > and should be removed. > > * If they are conditionally supported, like on Arm and AArch64, your > math-tests-trap.h is appropriate with a different comment explaining the > conditional support - but various fenv.h functions like feenableexcept > need to check for the support and give errors if asked to enable > exception traps they are unable to enable (this includes fesetenv and > feupdateenv passed FE_NOMASK_ENV - see Arm and AArch64 for examples). > Exception traps is design to be conditionally supported, seems define to no for compatibility. All the cpu with fpu have exception traps support at present and I have no method to check whether hardware support that, so I prefer to remove math-tests-trap.h. > > Several patches will be post to GCC and Binutils to fix some testcase fail > > later this month, while the follow results have these patches applied. > > Note that glibc ports can't go in while they depend on such non-upstream > patches for good results (see the ARC port discussion). You can send a > list of all the patches required to get the given test results, but > they'll need to be upstream (as will the Linux kernel port) before the > port can go into glibc. > I can understand the glibc patch and test-result should base on upstreamed gcc/binutils/linux. The purpose for this submission is to make sure there is no big issue in this patchset itself. Once other components are ready I can test the patch again and resubmit it easily. I'v got another issue while using build-many-glibcs.py. csky-linux-gnuabiv2-gcc can not recognise -profile during the make check stage and stoped. but it can recognise --profile. Is this a problem will block the c-sky glibc port goes in. > > 5. The following cases fail due to gcc optimize change the sequence of > > -a * b to -(a * b) and got 1ulps error. > > math/test-double-tgamma > > math/test-float-tgamma > > math/test-float32-tgamma > > math/test-float32x-tgamma > > math/test-float64-tgamma > > math/test-ldouble-tgamma > > So that needs a GCC bug fix (just like when the Arm and AArch64 ports of > GCC used to have such a bug). > We have this bug tracked internally. Also need to report a bug on gcc bugzilla? Thanks, Han Mao
On Thu, 13 Sep 2018, Mao Han wrote: > Hard float will use to vr to pass arguments, the ABI is imcompatible if the > function has any float-point arguments. I use the same dynamic linker names > because there is no float in ldso, the same ldso can be used on system with > soft float/hard float. Seems I still need to use different dynamic linker > names even if they are compatible, and distinct soft float/hard float in > bits/fenv.h to make glibc have correct definitions? A different dynamic linker name should be used because the ABI to libc and other glibc libraries is incompatible; if you have a different dynamic linker name for every ABI, that allows distributions using Debian-style multiarch directory arrangements to have libraries for both ABIs installed simultaneously. Then, because you can't sensibly use soft-float binaries with hard-float libm, you should have the conditionals in bits/fenv.h (a single installed header should be set up to work for both ABIs) so that it doesn't define macros for unsupported features for soft float. Once you have the conditionals in bits/fenv.h, the glibc testsuite will automatically disable tests for unsupported features for soft float, and internal calls to fenv.h functions within libm will automatically be optimized out for soft float. It's not required, but it's a good idea to make binutils check for ABI incompatibilities at static link time, using GNU object attributes, which GCC should generate based on the ABI selected when compiling. See how powerpc and mips handle this, for example. That helps protect against user mistakes (linking .o files for different ABIs together) by making the linker complain about such mixing. The Argument Passing section of the ABI document you provided doesn't seem to say anything about the different argument passing for hard float, so I think you need to update the document to cover that issue (likewise for return values if they are handled differently for hard float). (And the table in 2.2.1.2 would presumably also need to say what's used for argument passing.) > Exception traps is design to be conditionally supported, seems define to no > for compatibility. All the cpu with fpu have exception traps support at > present and I have no method to check whether hardware support that, so I > prefer to remove math-tests-trap.h. Yes, removing math-tests-trap.h until you are able to test on a platform without exception traps support seems reasonable. On Arm / AArch64, the processor specification is that the trap-enable bits in the control register always read as 0 if the processor does not support exception traps. Thus, the glibc implementations of relevant fenv.h functions read back the control register after writing it to see if the bits were set successfully. If C-SKY follows a similar specification, that would provide a way for the fenv.h functions to test whether traps were enabled as requested and return an error if not. > I'v got another issue while using build-many-glibcs.py. > csky-linux-gnuabiv2-gcc can not recognise -profile during the make check > stage and stoped. but it can recognise --profile. Is this a problem will > block the c-sky glibc port goes in. We want the build-many-glibcs.py build to succeed. You'll need to investigate why you see this problem. The -profile option is defined in gcc/config/gnu-user.opt which all *-linux* targets should be using, so you'll need to look at why you get an error there. > > > 5. The following cases fail due to gcc optimize change the sequence of > > > -a * b to -(a * b) and got 1ulps error. > > > math/test-double-tgamma > > > math/test-float-tgamma > > > math/test-float32-tgamma > > > math/test-float32x-tgamma > > > math/test-float64-tgamma > > > math/test-ldouble-tgamma > > > > So that needs a GCC bug fix (just like when the Arm and AArch64 ports of > > GCC used to have such a bug). > > We have this bug tracked internally. Also need to report a bug on gcc > bugzilla? No, you just need to get a fix for the problem checked in upstream; no need to file a bug in GCC Bugzilla.
On Thu, Sep 13, 2018 at 12:36:15PM +0000, Joseph Myers wrote: > A different dynamic linker name should be used because the ABI to libc and > other glibc libraries is incompatible; if you have a different dynamic > linker name for every ABI, that allows distributions using Debian-style > multiarch directory arrangements to have libraries for both ABIs installed > simultaneously. Then, because you can't sensibly use soft-float binaries > with hard-float libm, you should have the conditionals in bits/fenv.h (a > single installed header should be set up to work for both ABIs) so that it > doesn't define macros for unsupported features for soft float. > > Once you have the conditionals in bits/fenv.h, the glibc testsuite will > automatically disable tests for unsupported features for soft float, and > internal calls to fenv.h functions within libm will automatically be > optimized out for soft float. > OK. I've add different dynamic linker name name for hard-float and put some conditionals in bits/fenv.h, seems work fine. > It's not required, but it's a good idea to make binutils check for ABI > incompatibilities at static link time, using GNU object attributes, which > GCC should generate based on the ABI selected when compiling. See how > powerpc and mips handle this, for example. That helps protect against > user mistakes (linking .o files for different ABIs together) by making the > linker complain about such mixing. OK. I'll try to add some check here. > The Argument Passing section of the ABI document you provided doesn't seem > to say anything about the different argument passing for hard float, so I > think you need to update the document to cover that issue (likewise for > return values if they are handled differently for hard float). (And the > table in 2.2.1.2 would presumably also need to say what's used for > argument passing.) OK. We will update it. > We want the build-many-glibcs.py build to succeed. You'll need to > investigate why you see this problem. The -profile option is defined in > gcc/config/gnu-user.opt which all *-linux* targets should be using, so > you'll need to look at why you get an error there. > > > > > 5. The following cases fail due to gcc optimize change the sequence of > > > > -a * b to -(a * b) and got 1ulps error. > > > > math/test-double-tgamma > > > > math/test-float-tgamma > > > > math/test-float32-tgamma > > > > math/test-float32x-tgamma > > > > math/test-float64-tgamma > > > > math/test-ldouble-tgamma > > No, you just need to get a fix for the problem checked in upstream; no > need to file a bug in GCC Bugzilla. OK. My colleague Xianmiao Qu is working on these problems, will be fixed soon. Thanks, Han Mao
On Tue, Sep 18, 2018 at 02:22:11PM +0800, Mao Han wrote: > > It's not required, but it's a good idea to make binutils check for ABI > > incompatibilities at static link time, using GNU object attributes, which > > GCC should generate based on the ABI selected when compiling. See how > > powerpc and mips handle this, for example. That helps protect against > > user mistakes (linking .o files for different ABIs together) by making the > > linker complain about such mixing. > > OK. I'll try to add some check here. > Seems I just missunderstand to add some check in glibc configure. We have ABI check using eflag in elf header, which can recognize different ISA but not float ABI. We may support ABI check using GNU object attributes in the later version. Thanks, Han Mao
On Tue, 18 Sep 2018, Mao Han wrote: > On Tue, Sep 18, 2018 at 02:22:11PM +0800, Mao Han wrote: > > > It's not required, but it's a good idea to make binutils check for ABI > > > incompatibilities at static link time, using GNU object attributes, which > > > GCC should generate based on the ABI selected when compiling. See how > > > powerpc and mips handle this, for example. That helps protect against > > > user mistakes (linking .o files for different ABIs together) by making the > > > linker complain about such mixing. > > > > OK. I'll try to add some check here. > > > > Seems I just missunderstand to add some check in glibc configure. > We have ABI check using eflag in elf header, which can recognize different > ISA but not float ABI. > We may support ABI check using GNU object attributes in the later version. Object attributes are generally appropriate for the static linker (ld); checks of the ELF header are generally appropriate for the dynamic linker (ld.so).