This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] BZ #19590: Fixed build of shared objects that use libmvec.so functions
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Andrew Senkevich <andrew dot n dot senkevich at gmail dot com>, Florian Weimer <fweimer at redhat dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Wed, 10 Feb 2016 17:38:26 +0000
- Subject: Re: [PATCH] BZ #19590: Fixed build of shared objects that use libmvec.so functions
- Authentication-results: sourceware.org; auth=none
- References: <CAMXFM3tML81iuKQMKRU-T4Fw0+=sYk0q_BNavMGagt21VcYvzQ at mail dot gmail dot com> <56BB2835 dot 4050907 at redhat dot com> <CAMXFM3s=W79Wp=os1w0FuybqO8ygpQEz0mT=Q0-NDnX3wZTiPQ at mail dot gmail dot com> <56BB3610 dot 4040907 at redhat dot com> <CAMXFM3tzMWSMF-daxnwsFrMA8HyJ6J7k_WZvYciAGzAMusRBhg at mail dot gmail dot com> <CAMe9rOpu141Y_OLPtc8pXVzQqhik6EkQPfk=2PPX7CZ5AmhdLQ at mail dot gmail dot com> <CAMXFM3vUtxBHCCtZJn-fm1V5cObkyEo8Ow-i3FdLeZs8_BB5xQ at mail dot gmail dot com> <CAMe9rOocQG9Kc6iVL33rzM7=Xi9CjVSwDc673ophdUuOSS8KJw at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1602101631590 dot 20541 at digraph dot polyomino dot org dot uk> <CAMe9rOoSHgBt1TsnMWumZ3i=L0EPtyS947NmEGQuKfp8L-as_g at mail dot gmail dot com>
On Wed, 10 Feb 2016, H.J. Lu wrote:
> > It is deliberately only part of the static library ABI, not part of the
> > shared library ABI, because the shared libraries should not need more than
> > one internal-namespace exported name for the same interface (and it's a
> > compiler limitation that the other name exists at all).
> >
>
> Let me try to understand the problem:
>
> 1. GCC should generate an alias, foo, which points to bar defined
> in libmvec.so.
> 2. But the alias foo may be removed by GCC sometimes (LTO?).
> 3. As a workaround, we put an alias foo, in libmvec_nonshared.a which
> points to bar defined in libmvec.so.
>
> Am I correct?
Ideally the alias should not exist at all.
The issue is: function foo has two variants for scalar use (foo and
__foo_finite), where calls to foo get remapped to __foo_finite by
bits/math-finite.h under certain conditions. For a given vector type, it
has, logically, one variant (e.g. _ZGVbN2v_foo). But because GCC
determines the names to use when calling vector functions based on the
assembler name of the scalar function, sometimes it generates calls to
_ZGVbN2v___foo_finite instead.
Initially, this was worked around by using top-level asm statements in
bits/math-vector.h to set "_ZGVbN2v___foo_finite = _ZGVbN2v_foo". That
meant that the calls still resulted in references to _ZGVbN2v_foo instead
of _ZGVbN2v___foo_finite in the .o files. But remapping like that proved
not to solve the problem for LTO, so the wrapper _ZGVbN2v___foo_finite was
needed in libmvec_nonshared.a.
The sort of proper solution I envisage is a new attribute that can be used
in bits/math-vector.h, e.g. __attribute__ ((__vector_asm_name__ ("foo"))),
which would mean that the given string is used as the basis for forming
names of vector function variants, instead of using the
DECL_ASSEMBLER_NAME. That way, glibc headers could determine the name of
the scalar version to use (specified with asm) and the name to use as the
basis for vector versions' names (specified with that attribute)
independently.
--
Joseph S. Myers
joseph@codesourcery.com