Defining macros for function symbol versions

[Joseph Myers <joseph at codesourcery dot com>]

I have a possible use for an automatically-generated header (used in the 
build, not installed) that defines macros for the first symbol version at 
which each symbol was added.  E.g.

#define FIRST_VERSION_libm_fmaxl GLIBC_2_1

The place in the build that seems closest to having this information is 
versions.awk, where it reads the Versions.tmp file to generate .map files 
for each library.  Does it seem reasonable to make this code also process 
the lists of symbol names in Versions.tmp to generate a corresponding 
header?

My motivation is as follows.  Consider 
sysdeps/ieee754/ldbl-opt/math-type-macros-double.h.  It has a long list of 
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?".  Those could be 
replaced by the generated FIRST_VERSION_* macros.

That's a first use for such a header.  With additional macros 
automatically defined for each function, there are further uses.  Consider 
how ldbl-opt has its own versions of recently added long double functions 
that use type-generic templates, to avoid math-type-macros-ldouble.h using 
long_double_symbol for them (s_nextdownl.c s_canonicalizel.c w_llogbl.c).  
Requiring additional files like that for new functions is not ideal.  I 
imagine math-type-macros-ldouble.h instead doing something like

#define declare_mgen_alias(from, to) \
  maybe_long_double_symbol (libm, from ## l, to ## l);

where maybe_long_double_symbol(lib, from, to) expands to use 
long_double_symbol or weak_alias depending on when the symbol was added to 
libm.  What that probably needs is a further macro defined for each 
function, that chooses one or another of its arguments depending on how 
LONG_DOUBLE_COMPAT evaluates (i.e. is defined conditional on a #if on 
LONG_DOUBLE_COMPAT).  Then for old functions the templates would end up 
calling long_double_symbol and for new functions they'd end up calling 
weak_alias, and templates for new and old functions could look the same.

I think that should enable eliminating many of the wrappers in ldbl-opt 
and ldbl-64-128 that include another file but adjust how function aliases 
are generated.  Making the generation of libm function aliases more 
uniform and more based on common macros is attractive for support for TS 
18661-3 function aliases (*f32, *f64, *f128, *f32x, *f64x, where those 
names match the semantics of existing float, double or long double 
functions) - to add such aliases, it's desirable for alias generation to 
use common macros as far as possible, so that lots of individual function 
sources don't need changing to add the new names and only the definitions 
of those macros need to be conditional on e.g. whether ldbl-96 or ldbl-128 
functions should get *f64x aliases or not.  (To be clear, I do not intend 
to add any such aliases for 2.25 and we still need to discuss consensus on 
adding such aliases, as opposed to *f128 functions where that's a distinct 
format from long double, where I think we have consensus.)

Any comments on this notion of adding such macros for the first symbol 
version with a function (and other such per-function macros as needed to 
get things to expand based on LONG_DOUBLE_COMPAT conditionals)?

-- 
Joseph S. Myers
joseph@codesourcery.com