Re: Create and use first-versions.h with macros for function symbol versions

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 21 Apr 2017, Andreas Schwab wrote:

> On Apr 21 2017, Joseph Myers <joseph@codesourcery.com> wrote:
> 
> > This patch arranges for the glibc build to generate a header
> > first-versions.h that defines macros for the earliest symbol version
> > in which each public symbol (GLIBC_[0-9]* symbol version, name only
> > uses C identifier characters) is available.
> >
> > This is used in sysdeps/ieee754/ldbl-opt/math-type-macros-double.h to
> > replace the manually defined LDOUBLE_*_libm_version macros for various
> > functions defined using type-generic templates, the purpose of which
> > is to use in LONG_DOUBLE_COMPAT tests "was this function originally
> > added before glibc supported long double != double on this platform?".
> 
> This won't always be the first version of a symbol, so the first version
> can be non-fitting.

For all the functions where the FIRST_VERSION_libm_* macros are used by my 
patch (which are functions built from type-generic templates), for all 
platforms currently supported by glibc, the version in question is right 
(as evidenced by unchanged stripped binaries).

For the test "was this function originally added before glibc supported 
long double != double on this platform?", a simple comparison of the first 
version for that function with the version where long double != double 
support *does* always suffice.

It's true that if there was more than one symbol version for long double = 
double before long double != double support was added, then generating the 
compat symbols (as opposed to telling whether any such symbols are needed) 
would be more complicated (that is, the default declare_mgen_libm_compat 
definition would not suffice).  For example, if a platform with long 
double = double were to gain distinct long double support now, the symbol 
versioning support for lgamma might be more complicated.  But for all the 
existing functions using FIRST_VERSION_libm_*, and I think for the vast 
bulk of other libm functions that currently have special ldbl-opt versions 
to handle symbol versioning for such a change, there is only one version 
before that change and so logic based on the first version suffices.

-- 
Joseph S. Myers
joseph@codesourcery.com