This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2] Aarch64: Add simd exp/expf functions
On Tue, 28 May 2019, Wilco Dijkstra wrote:
> Hi Joseph,
>
> > There's an interesting implication here - that Wilco's patches should also
> > be removing the *existing* x86_64 libmvec *_finite aliases and tests
> > thereof (because they are static-only, so not relevant for compatibility
> > with existing executables and shared libraries - and we don't claim to
> > keep compatibility with existing .o files when we obsolete a feature).
>
> You mean sysdeps/x86_64/fpu/svml_finite_alias.S and test-libmvec-alias-mod.c?
There seem to be more files involved in testing those aliases, but that's
the general idea.
> > A more significant omission in that area from Wilco's patches is that all
> > the _finite aliases in libm (as opposed to libmvec) need to be conditioned
> > on SHLIB_COMPAT (libm, GLIBC_2_15, GLIBC_2_30), as if we're obsoleting the
> > aliases that means they should not become part of the ABI for any future
> > glibc ports.
>
> So concretely, does this mean the strong aliases need to have a #if around it
> like:
>
> #if SHLIB_COMPAT (libm, GLIBC_2_15, GLIBC_2_30)
> strong_alias (__ieee754_cosh, __cosh_finite)
> #endif
Yes. They also need to change from strong_alias to compat_symbol calls,
of the form:
compat_symbol (__ieee754_cosh, __cosh_finite, GLIBC_2_15)
(If any functions have existing versioned_symbol calls you may need to add
another alias to use in the compat_symbol call, because of assembler
requirements that each symbol version gets defined using a different name
for the original symbol. Hopefully any such cases are rare, but this
probably applies to a few functions such as expf, for example, where new
symbol versions were added as part of eliminating wrappers.)
*Calls* to the _finite functions will need updating to call other public
names for those functions. There are a few calls of WRAPPER_IMPL_SSE2
etc. in sysdeps/x86_64/fpu/, and calls to the _finite functions from .S
files in sysdeps/x86_64/fpu/multiarch/, that need updating. (There might
be other calls, I haven't done an exhaustive check.)
> Do the abi lists need to be changed too?
No. The ABI lists do not distinguish whether a symbol is a compat symbol
or not. Testing with build-many-glibcs.py to verify that all the ABI
tests still pass is a good idea to verify that the patch hasn't
accidentally broken the ABI.
--
Joseph S. Myers
joseph@codesourcery.com