Re: [RFC] Fix float128 IFUNC relocations on ppc64le [BZ #21707]

[Carlos O'Donell <carlos at redhat dot com>]

On 07/05/2017 03:19 PM, Florian Weimer wrote:
> On 07/05/2017 07:23 PM, Tulio Magno Quites Machado Filho wrote:
> 
>>    ARCH_INIT_CPU_FEATURES ();
>>  
>> -  /* Perform IREL{,A} relocations.  */
>> -  apply_irel ();
>> -
>>    /* The stack guard goes into the TCB, so initialize it early.  */
>>    __libc_setup_tls ();
>>  
>> +  /* Perform IREL{,A} relocations.
>> +     Note: the relocations must happen after TLS initialization so that
>> +     IFUNC resolvers can benefit from thread-local storage, e.g. powerpc's
>> +     hwcap and platform fields available in the TCB.  */
>> +  apply_irel ();
>> +
> 
> __libc_setup_tls calls memcpy and a lot of other stuff, so I'm not sure
> if this change is correct on all architectures.

I audited this, and it looks like we don't IFUNC memcpy in libc.a, probably
because of this issue, we use memcpy very very early.

A new test like I suggest would make sure we don't regress this.

>> +# libgcc requires __tcb_parse_hwcap_and_convert_at_platform when built with
>> +# a binary128 type.  That symbol is provided by the loader on dynamically
>> +# linked executables, forcing to link the loader after libgcc link.
>> +f128-loader-link = $(as-needed) $(elf-objpfx)ld.so $(no-as-needed)
> 
> Why doesn't the regular linker invocation take care of this?  Will user
> applications run into the same issue?

We don't use the regular linker invocation in glibc builds? We have to emulate
what the actual toolchain would do in this case.

I would expect that users using gcc as the normal driver would get ld.so
included as needed.

Tulio can answer more authoritatively here.

-- 
Cheers,
Carlos.