From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62967 invoked by alias); 19 Jan 2017 18:43:14 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 59932 invoked by uid 89); 19 Jan 2017 18:43:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS,URIBL_RED autolearn=no version=3.3.2 spammy=carlosredhatcom, carlos@redhat.com, Bs, relying X-HELO: mail-ua0-f193.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FKYovsJOQeyB00Ngp+6QdxONvUro8u7uNsgfryVsKC0=; b=QCNLgK5PoIMWcYwcQie3JIfdLYfT7OM29LSOjSJ8ng1EWwuIle5sLq/yaS2fiYxqlY NeafGRa2OrazhDMtu2+jeyYSzNK4Z8hrYukSWk//o/CSLgqqNTViCrSzx3PKURMytbvv h23RyFqP4hSn8+9eB6TUnvPPs9cDUk02d2p/M0KBEiLh83VkLc16gjpo6OB4xQEZDoLp SpHHfTgIJ9BTkTmUw3xc2Az++g6aFJPml7+kZZ8uV+he2pRzPwc5hylodwkDUoTF3ty4 5QJjmu7FxqxO1IZPrOj/P8xvxHTzDQA+OE944DyoFEt029sbyF5BWr3nuZBzk+fBg4Au XxwA== X-Gm-Message-State: AIkVDXIMqtfGKWx3az2NUOxPfiahcJMep9LczgqAsmpwgTCV7ceoZ+0EMxI1QKDpX8+DE6eSapjjJewu3iO08w== X-Received: by 10.176.83.218 with SMTP id l26mr4633021uaa.69.1484851378819; Thu, 19 Jan 2017 10:42:58 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <20161004184621.GB27454@intel.com> <00fa4a04-7c02-fe70-7892-3f6f90f733cb@gmail.com> From: Khem Raj Date: Thu, 19 Jan 2017 18:43:00 -0000 Message-ID: Subject: Re: [PATCH 2/2] Add an x86 IFUNC testcase for [BZ #20019] To: "H.J. Lu" Cc: GNU C Library Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2017-01/txt/msg00391.txt.bz2 On Fri, Jan 13, 2017 at 12:15 PM, H.J. Lu wrote: > On Fri, Jan 13, 2017 at 11:30 AM, Khem Raj wrote: >> >> >> On 1/13/17 11:03 AM, H.J. Lu wrote: >>> On Wed, Oct 12, 2016 at 3:19 PM, H.J. Lu wrote: >>>> On Tue, Oct 11, 2016 at 10:45 PM, Carlos O'Donell wrote: >>>>> On 10/05/2016 02:16 PM, H.J. Lu wrote: >>>>>> On Tue, Oct 4, 2016 at 5:09 PM, Joseph Myers 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. > > -- > H.J.