This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v4 00/13] port C-SKY to glibc

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 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 
> 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 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.

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]