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: "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 <joseph@codesourcery.com> 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)
> independently.
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?
--
H.J.