Re: [PATCH 4/4] Use compat_symbol for _finite symbols

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 24/07/2019 18:02, Joseph Myers wrote:
> On Wed, 26 Jun 2019, Wilco Dijkstra wrote:
> 
>> diff --git a/sysdeps/ieee754/float128/float128_private.h b/sysdeps/ieee754/float128/float128_private.h
>> index f3917b463837e9eb19d18c62ba232d9bb077e9a1..c7bb208efb024030f0ae7cc71a01dab1d42c4fa1 100644
>> --- a/sysdeps/ieee754/float128/float128_private.h
>> +++ b/sysdeps/ieee754/float128/float128_private.h
>> @@ -365,3 +365,12 @@ mul_splitf128 (_Float128 *hi, _Float128 *lo, _Float128 x, _Float128 y)
>>    *lo = (((x1 * y1 - *hi) + x1 * y2) + x2 * y1) + x2 * y2;
>>  #endif
>>  }
>> +
>> +/* Ensure compat_symbol uses GLIBC_2_26 since that was when the
>> +   __<fn>f128_finite symbols were introduced.  */
>> +#include <shlib-compat.h>
>> +#if SHLIB_COMPAT (libm, GLIBC_2_26, GLIBC_2_30)
>> +# undef compat_symbol
>> +# define compat_symbol(lib, local, symbol, version) \
>> +  compat_symbol_reference (lib, local, symbol, GLIBC_2_26)
>> +#endif
> 
> This is implicitly embedding an action-at-a-distance assumption that the 
> only case for using compat_symbol in float128 code is for functions added 
> in 2.26 and obsoleted in 2.30.  That seems excessively fragile to me.
> 
> How about having
> 
> #define FINITE_VERSION GLIBC_2_15
> 
> somewhere, with float128_private.h overriding that to GLIBC_2_26, and then 
> all the relevant SHLIB_COMPAT and compat_symbol calls using FINITE_VERSION 
> instead of GLIBC_2_15?  That way you avoid causing nonobvious problems for 
> any post-2.26 *f128 symbols that might get obsoleted in future.
> 

My suggestion [1] was to use a new macro, libm_alias_finite, which uses the
FIRST_VERSION_libm_* macro from first-version.h under the hood; plus some
extra macros on float128_private.h to redirect the symbols names the 
internal '__name128'.

https://sourceware.org/git/?p=glibc.git;a=commit;h=148de5f248d5f6fe58300e231e3033c12d8646ca