This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/2] Add an x86 IFUNC testcase for [BZ #20019]
- From: Khem Raj <raj dot khem at gmail dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 20 Jan 2017 12:41:09 -0800
- Subject: Re: [PATCH 2/2] Add an x86 IFUNC testcase for [BZ #20019]
- Authentication-results: sourceware.org; auth=none
- References: <20161004184621.GB27454@intel.com> <alpine.DEB.2.20.1610042122170.17011@digraph.polyomino.org.uk> <CAMe9rOrvz5nZZUVMq5qc_FT2g9iKzpGQ6-ydESmmm3CP5BVmJg@mail.gmail.com> <alpine.DEB.2.20.1610042253170.17011@digraph.polyomino.org.uk> <CAMe9rOpzKV4oLgCrX+scC=MVH-TM_TRAcOZrLUg06L0YvEZuRw@mail.gmail.com> <alpine.DEB.2.20.1610050009080.17011@digraph.polyomino.org.uk> <CAMe9rOrtbOXOKYa2fiazJZb0WfZ0KbRr0thwvYOTdL=D3qHt-g@mail.gmail.com> <bc2016fe-c194-582b-dc80-a6392d51aa17@redhat.com> <CAMe9rOr=LKK6XVHGh2uehYgkRhLmEXMcEsdP25zd0ny8GPGfBA@mail.gmail.com> <CAMe9rOpEYGGw3MxO9v+J0u3WWN1A-Nm8p9=J1m7_7g9SA4e3pg@mail.gmail.com> <00fa4a04-7c02-fe70-7892-3f6f90f733cb@gmail.com> <CAMe9rOpfYBeM+kmL38zVgrPa-b-hk2rOLd7Rf_8hRPXPphJbWw@mail.gmail.com> <CAMKF1sqrUisi=TsWBYkB3WoRUMjuKAS0iOokFEuQV0XRCg9p5w@mail.gmail.com> <CAMe9rOqssgAesmUr9r1zHc1Lzb1XffrFNcewbEL1C1bsrMjwJQ@mail.gmail.com> <CAMKF1sqphKdNv=EDrMzu=m6neMcK8G27gPxWnsGgbLUzhzh_2Q@mail.gmail.com> <CAMe9rOoi0+qaNs7Kfs+BfN5z+cOF-V94_EzBqtjTtbTU5GXBrQ@mail.gmail.com>
On Fri, Jan 20, 2017 at 11:02 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Fri, Jan 20, 2017 at 10:35 AM, Khem Raj <raj.khem@gmail.com> wrote:
>> On Fri, Jan 20, 2017 at 9:00 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Thu, Jan 19, 2017 at 10:42 AM, Khem Raj <raj.khem@gmail.com> wrote:
>>>> On Fri, Jan 13, 2017 at 12:15 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>> On Fri, Jan 13, 2017 at 11:30 AM, Khem Raj <raj.khem@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>> On 1/13/17 11:03 AM, H.J. Lu wrote:
>>>>>>> On Wed, Oct 12, 2016 at 3:19 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>>>> On Tue, Oct 11, 2016 at 10:45 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>>>>>>>>> On 10/05/2016 02:16 PM, H.J. Lu wrote:
>>>>>>>>>> On Tue, Oct 4, 2016 at 5:09 PM, Joseph Myers <joseph@codesourcery.com> wrote:
>>>>>>>>>>> On Wed, 5 Oct 2016, H.J. Lu wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I can try __builtin_memcpy, instread of __builtin_memmove. There are 2
>>>>>>>>>>
>>>>>>>>>> I changed it to use __builtin_memset.
>>>>>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>> You could make the test pass on either of those results (while failing if
>>>>>>>>>>> ld.so crashes).
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I moved the test to elf. It passes if the test runs or ld.so issues an
>>>>>>>>>> error. Please try it on arm, powerpc and s390.
>>>>>>>>>
>>>>>>>>> This is the wrong way to test this.
>>>>>>>>>
>>>>>>>>> The point of this test is this:
>>>>>>>>>
>>>>>>>>> - Verify that an unversioned symbol reference in DSO A which has no DT_NEEDED
>>>>>>>>> on DSO B, when resolved to a symbol definition in DSO B, when the symbol in
>>>>>>>>> DSO B is an IFUNC with a resolver, that DSO B is relocated _before_ the IFUNC
>>>>>>>>> resolver is called, because DSO B's resolver might need global data to make
>>>>>>>>> the IFUNC decision e.g. GOT setup.
>>>>>>>>>
>>>>>>>>> The invariant we want to hold true for IFUNC is that to call the resolver
>>>>>>>>> function you must have relocated the DSO which contains the resolver. This _should_
>>>>>>>>> have been done by a symbol reocation dependency analysis, but that isn't working
>>>>>>>>> correctly IMO or needs deeper analysis in the dynamic loader.
>>>>>>>>>
>>>>>>>>> The solution we want in place today is to issue some kind of diagnostic until we
>>>>>>>>> fix the real problem.
>>>>>>>>>
>>>>>>>>> The test should look like this:
>>>>>>>>>
>>>>>>>>> - DSO A with an unversioned symbol reference to 'foo'.
>>>>>>>>> - DSO B with a symbol definition of 'foo' as an ifunc with 'foo_resolver' as the
>>>>>>>>> resolver function which references global data from DSO C to decide which of
>>>>>>>>> two functions to return.
>>>>>>>>> - DSO C with global data set to a value.
>>>>>>>>>
>>>>>>>>> The point is that DSO B depends on DSO C and has DT_NEEDED on it, so C will get
>>>>>>>>> relocated first, then B, such that B's GOT is setup to access C's global data.
>>>>>>>>>
>>>>>>>>> When handling the reference to 'foo' in DSO A we should on x86_64 and i686
>>>>>>>>> get the error about needing to relink DSO A so it depends on DSO B, to form
>>>>>>>>> the initialization order of C->B->A.
>>>>>>>>>
>>>>>>>>> I expect this test case will now crash the other arches, rather than just
>>>>>>>>> avoiding the crash by relying on internal libc.so details about which ifuncs
>>>>>>>>> you're using.
>>>>>>>>>
>>>>>>>>> This is one step towards a better definition of IFUNC semantics, which need to
>>>>>>>>> be more clearly defined (something I wish I had time to define and fix so
>>>>>>>>> more projects could use them).
>>>>>>>>
>>>>>>>> IFUNC resolver can fail for various reasons. My goal is to make sure
>>>>>>>> that IFUNC inside of glibc works correctly or an error message is given
>>>>>>>> when glibc isn't used properly. In case of x86, CPU feature info is
>>>>>>>> retrieved and stored in ld.so very early at startup, which is used by IFUNC
>>>>>>>> and only accessible in libc.so and libm.so after they have been relocated.
>>>>>>>> My change in x86 ld.so checks it and my test verifies the check. My fix
>>>>>>>> won't cover other possible IFUNC failures.
>>>>>>>>
>>>>>>>
>>>>>>> When the IFUNC relocation is performed before the providing shared
>>>>>>> library is unrelocated, the returned function address will be 0 and
>>>>>>> program will segfault when the function is called.
>>>>>>>
>>>>>>> Please apply this patch and run the test if your platform has IFUNC. I only
>>>>>>> enabled the unsafe resolver check for i386 and x86-64. It is straightforward
>>>>>>> to add check for other platforms.
>>>>>>
>>>>>> I will test it out shortly. One thing I see, the runner script for test
>>>>>> is calling out for /bin/bash and the script does not use any bash
>>>>>> extentions perhaps using /bin/sh is enough.
>>>>>>
>>>>>
>>>>> Here is the updated patch with some fixes.
>>>>
>>>> This still failed on 32bit in same way.
>>>>
>>>
>>> Did you get segfault?
>>
>> No, I was testing it for https://sourceware.org/bugzilla/show_bug.cgi?id=21041
>> I am getting same ldso IFUNC messages
>
> I updated ld.so for i686 and x86-64 so that ld.so issues an error message,
> instead of segfautl. Have you tested it on non-x86 machines?
I think its working ok on others. I do not see segfaults
>
> --
> H.J.