Create and use first-versions.h with macros for function symbol versions
Joseph Myers
joseph@codesourcery.com
Fri Apr 21 16:50:00 GMT 2017
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
More information about the Libc-alpha
mailing list