From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126449 invoked by alias); 12 Oct 2016 05:45:45 -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 126148 invoked by uid 89); 12 Oct 2016 05:45:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,URIBL_RED autolearn=no version=3.3.2 spammy=Cs, C's, c's, ld.so X-HELO: mail-io0-f170.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=xtCq9Y4O2CejDMyryUTgIdEbITVbyDTdaXNL2Gw3DaY=; b=YRr9+YS2wtlYKid9ppeen4eZRIns69oWA7UU4UmCC4V4YsZyY12QFa0VBjJ5KJdXne v6cpq9ZGSdAY+MzE60wlpu8LvzuN9+Ft1v95qf15LaCXNV0qCVsXqgrAOMmWEiM41/P1 NfAu6PtTClM0QTbtWsCaKrt4HIfW/URtRXQ51w7bsr8rl2jqKGfjPUj+tuaoItWZGjwj p8KPFaOOZUg7zm2HZsXXEcyjYNxpmqTBTI2v4Mvny0DfKvMOZxyOGgAEBscUICxOBiKQ V+3JbeNv2vjECTX6bGTAR13c0ljoaFHa/IsSHil8bJJInfQcNRV1BUufc0fMK1xfhfDC lghw== X-Gm-Message-State: AA6/9RnDPlE/CBh0NUOUrk7jLsCjZ6EeUydwzV2LhG6xwYP8p/k9wS6L/jLP589waHrhMlxz X-Received: by 10.107.158.85 with SMTP id h82mr1743077ioe.152.1476251121344; Tue, 11 Oct 2016 22:45:21 -0700 (PDT) Subject: Re: [PATCH 2/2] Add an x86 IFUNC testcase for [BZ #20019] To: "H.J. Lu" , Joseph Myers References: <20161004184621.GB27454@intel.com> Cc: GNU C Library From: Carlos O'Donell Message-ID: Date: Wed, 12 Oct 2016 05:45:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00217.txt.bz2 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). -- Cheers, Carlos.