This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] BZ #19590: Fixed build of shared objects that use libmvec.so functions
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Joseph Myers <joseph at codesourcery 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 10:11:24 -0800
- 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> <alpine dot DEB dot 2 dot 10 dot 1602101730240 dot 20541 at digraph dot polyomino dot org dot uk>
On Wed, Feb 10, 2016 at 9:38 AM, Joseph Myers <firstname.lastname@example.org> wrote:
> 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)
Since the proper fix involves both GCC and glibc, do we have bugs
open for GCC and glibc so that it won't get lost?