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] BZ #19590: Fixed build of shared objects that use libmvec.so functions


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.


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