Re: [PATCH 2/2] Add an x86 IFUNC testcase for [BZ #20019]

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Tue, Oct 4, 2016 at 3:55 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Tue, 4 Oct 2016, H.J. Lu wrote:
>
>> On Tue, Oct 4, 2016 at 2:27 PM, Joseph Myers <joseph@codesourcery.com> wrote:
>> > On Tue, 4 Oct 2016, H.J. Lu wrote:
>> >
>> >> If an IFUNC function is called before the providing shared library is
>> >> unrelocated, ld.so may segfault.  Add a testcase to verify that ld.so
>> >> will issue a diagnostic and won't segfault in this case.
>> >>
>> >> Tested on i686 and x86-64.  OK for master?
>> >
>> > I can't see anything x86-specific about these tests.  If they are meant to
>> > work, they should work on all architectures, and so should be
>> > architecture-independent.  Is the architecture-specific thing the use of
>> > memmove as a function that uses IFUNCs?  If so, the tests should still
>> > work on other architectures, just maybe be less effective as tests (and
>> > other architecture maintainers could always add a hook to use another
>> > function instead of memmove).
>>
>> The result of this test is IFUNC implementation specific.  The older
>> x86 IFUNC implementation had
>>
>> # define INIT_ARCH() \
>>   do                                                    \
>>     if (__cpu_features.kind == arch_kind_unknown)       \
>>       __init_cpu_features ();                           \
>>   while (0)
>>
>> The new implementation assumed that relocations in libc.so were
>> processed first.  It is hard for me to tell if other IFUNC implementations
>> have the similar restriction.
>
> You seem to be saying there was some bug in the x86 IFUNC implementation

It is a limitation.

> such that you don't know whether a corresponding bug might be present for
> other architectures or not.  That is a very strong indication that the
> tests should be architecture-independent, so that people can use the
> results of those tests on other architectures to tell whether those other
> architectures need fixing as well.
>

I can try __builtin_memcpy, instread of __builtin_memmove.   There are 2
acceptable results.  One is ld.so issues an error and the other is program runs.
On x86, ld.so issues an error.  I don't know what should happen on others.

-- 
H.J.