This is the mail archive of the libc-alpha@sourceware.org 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: Prefer new libm function wrappers for !LIBM_SVID_COMPAT [committed]


On 06/09/17 00:36, Joseph Myers wrote:
> The initial obsoletion of SVID libm error handling left the old
> wrappers and __kernel_standard still being used for new ports and
> static linking, just with macro definitions of _LIB_VERSION and
> matherr that meant symbols with those names were never actually used
> and the code for different error handling variants could be optimized
> out.
> 
> This patch cleans things up further by eliminating the
> __kernel_standard use for new ports and static linking.  Now, the old
> wrappers no longer generate any code in the !LIBM_SVID_COMPAT case,
> while the new errno-only wrappers that were added for float128 support
> are now also used for float, double and long double in that case.
> 
> The changes are generally straightforward.  The w_scalb*_compat
> wrappers continue to be used (scalb is obsolescent in the sense of not
> being supported for float128, but is present in supported standards -
> the 2001 edition of POSIX and earlier XSI versions - so remains
> supported for static linking and new ports, as do the float and long
> double variants that are existing GNU extensions).  Those wrappers
> would only call __kernel_standard in the _LIB_VERSION == _SVID_ case.
> Since we would like to be able to compile most of glibc without
> optimization, relying on a static function whose only use is under an
> if (0) condition being optimized away to avoid an undefined
> __kernel_standard reference may not be a good idea.  Thus, the
> relevant code in the scalb wrappers has LIBM_SVID_COMPAT conditionals
> added to guarantee it's not built at all in the case where
> __kernel_standard does not exist.
> 
> Just as i386 has its own w_sqrt_compat.c, so w_sqrt.c is also added.
> ia64 gets dummy w_*.c to prevent those files being built where they
> would conflict with the ia64 libm, as with its existing w_*_compat.c.
> 
> Conditions disabling code for !LIBM_SVID_COMPAT are needed in both the
> math/ wrappers and in the long double wrappers in ldbl-opt (to avoid
> them setting up aliases and symbol versions for undefined symbols).  I
> hope that future cleanups to how libm function aliases and symbol
> versioning are done will eliminate the need for most of the ldbl-opt
> wrappers.
> 
> Tested for x86_64 and x86, and with build-many-glibcs.py.  Committed.
> 
> 2017-09-05  Joseph Myers  <joseph@codesourcery.com>
> 
> 	* sysdeps/generic/math-type-macros-double.h: Include
> 	<math-svid-compat.h>.
> 	(__USE_WRAPPER_TEMPLATE): Define to !LIBM_SVID_COMPAT.
> 	* sysdeps/generic/math-type-macros-float.h: Include
> 	<math-svid-compat.h>.
> 	(__USE_WRAPPER_TEMPLATE): Define to !LIBM_SVID_COMPAT.
> 	* sysdeps/generic/math-type-macros-ldouble.h: Include
> 	<math-svid-compat.h>.
> 	(__USE_WRAPPER_TEMPLATE): Define to !LIBM_SVID_COMPAT.
> 	* math/lgamma-compat.h (BUILD_LGAMMA): Include LIBM_SVID_COMPAT
> 	condition.

i think this change made the gammaf, gamma, gammal
weak aliases disappear on new targets.

(at least i don't have those symbols after i rebase
the arm/ilp32 patches now, they used to come from
math/w_lgamma*_compat2.os)

i don't think it's safe to remove them for new targets
since they are still in the public math.h


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