From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17907 invoked by alias); 20 Jan 2017 19:02:41 -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 17710 invoked by uid 89); 20 Jan 2017 19:02:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-HELO: mail-yb0-f194.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=ztK+hu+YNfd9gACSYDitgt3HT1OYK8paAf8WKBLQreo=; b=iMoRrwj/jXgN5vVBl/J403ZC7AexOx7oBT1YXL00j5kCRt1JfD4vENXEUxoJ+Elr6T 6HNL+LgCKpJf0dde0jgluIvyBl4WgXBw0IeqUOuuVBZWJIjYeyQYnyvvEh9cxODEOhdi ZRiqw1ymou2fhxeldUNKq8tTni+lCJBEJKpKdoaGIFTsHKy+g0Obi57tkpeTdsTzFlL6 P1lPk6ChXQxpYc7W1ZkUy3Yi5Umhqu0K8z/azFWVE3Z/zDiNymfjmeABtbtph3WIOitr 13qSKd9EUFRjEo8PsoVKCYqqC3bdwQ/113jTwfGmU0R5IGwpDU4ipbZ8t38Uutp9bAEp gMbQ== X-Gm-Message-State: AIkVDXIp2daUo2U8Pi1hByxn/3ayNininuUEc6VFGwpN5Uom7wL7+AckcYRhzh6OtD80JsH56Vab7QD3NI8Xug== X-Received: by 10.237.53.236 with SMTP id d41mr14170175qte.135.1484938946975; Fri, 20 Jan 2017 11:02:26 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <20161004184621.GB27454@intel.com> <00fa4a04-7c02-fe70-7892-3f6f90f733cb@gmail.com> From: "H.J. Lu" Date: Fri, 20 Jan 2017 19:02:00 -0000 Message-ID: Subject: Re: [PATCH 2/2] Add an x86 IFUNC testcase for [BZ #20019] To: Khem Raj Cc: GNU C Library Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2017-01/txt/msg00407.txt.bz2 On Fri, Jan 20, 2017 at 10:35 AM, Khem Raj wrote: > On Fri, Jan 20, 2017 at 9:00 AM, H.J. Lu wrote: >> On Thu, Jan 19, 2017 at 10:42 AM, Khem Raj wrote: >>> 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. >>> >> >> 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? -- H.J.