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: [RFC] Fix float128 IFUNC relocations on ppc64le [BZ #21707]


Carlos O'Donell <carlos@redhat.com> writes:

> On 07/05/2017 01:23 PM, Tulio Magno Quites Machado Filho wrote:
>>> On 06/27/2017 09:05 AM, Florian Weimer wrote:
>>>> On 06/27/2017 01:02 AM, Joseph Myers wrote:
>>>>> I'm seeing a testsuite regression for powerpc64le with
>>>>> build-many-glibcs.py with this patch (elf/check-localplt fails), did you
>>>>> not see that in your testing?
>>>>>
>>>>> https://sourceware.org/ml/libc-testresults/2017-q2/msg00427.html
>>>>>
>>>>> The failure is: "Extra PLT reference: libc.so: __getauxval".  As the
>>>>> __getauxval reference comes from have_ieee_hw_p in libgcc, presumably you
>>>>> need to allow that PLT reference in localplt.data with an appropriate
>>>>> comment, as it won't be readily possible to avoid it.
>>>>
>>>> The __getauxval call happens from IFUNC resolvers and violates current
>>>> guidelines regarding what can be done from IFUNC resolvers.  This is
>>>> another reason to get rid of the PLT reference.
>>>>
>>>> My IFUNC resolver enhancements are not ready for 2.26, and I plan to
>>>> wait for DJ's dl-minimal malloc improvements to land, rather than
>>>> rolling my own memory allocator to back the IFUNC resolver queue.
>>>
>>> The above isn't correct because even if you can call getauxval, it
>>> doesn't have the data to return meaningful results during relocation.
>>> This currently breaks --enable-bind-now builds on pcp64le:
>>>
>>>   https://sourceware.org/bugzilla/show_bug.cgi?id=21707
>> 
>> I agree.
>> 
>>> For the time being, we just disable --enable-bind-now, but I'd prefer a
>>> proper fix, perhaps the one suggested here:
>>>
>>>   https://sourceware.org/ml/libc-alpha/2017-06/msg01383.html
>> 
>> Unfortunately, this patch creates another issue: the thread pointer is not
>> initialized at the time of IRELA relocations in static executables.
>> 
>> The following changes solve this issue.
>
> OK to checkin with a test.
>
> You need a static program with an IFUNC resolver that touches a __thread
> variable and fails before your patch, and passes after. This is marginal
> proof that TLS is operational after your change. Have the resolver set the
> TLS variable to some value and check that value in main.

It wasn't my intention to allow writing to the TLS from an IFUNC resolver.
It was intended to enable reading from the TCB.
Writing to the TLS during IRELA relocation is still not allowed because the
initialization of thread-local variables happen after relocating all objects
in a dynamically-linked executable.

So, I adapted your test to read the address of a thread-local variable
and included tests both for statically and dynamically-linked executables
in the version 2 of the patch.

Thanks!

-- 
Tulio Magno


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