This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]