From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112200 invoked by alias); 11 May 2017 17:33:07 -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 112149 invoked by uid 89); 11 May 2017 17:33:06 -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,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=H*f:sk:czMaAo9, H*f:JU_ECHjOD_ X-HELO: mail-io0-f171.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=vIzGzRUxP9s0gndJx9MYudYGuIRBX09Lg8ev2/ywQYM=; b=ctZTSO/uwHx9Ayqv/Mvuz2jiy5fhJOQ0BAuDx+GqkXA2TqGt7wT4a4q376zF38omQf Bg0/GSpWCDg7ro5GzzRyvLuh8TuYU5h97whH3Qf3INtlvX2NZQwsTdXhxQULx1FIxQU4 DCeyojhL1mrwk/1czNFPUlih3OsQokz8bQrX25cBeYIRCTG8LBlHd4ZETGnbjXsDkUxU +l25s6vu5Iki7nSmlSQO+Z7pOO6pjM0aRixWjil29xmXCS6UbKYdM0kbjYmjhbOxEazc zTEG934aqJ/BZPy6mFOiKF9VtF+7D0iCPVvk0q60qfiZkcBD6Frr8s8ZkwMz0F7lU9JH vc5Q== X-Gm-Message-State: AODbwcA4xOJ/ofxSVUTwnpyMVMy5OxyO3haTCI+eer8tRZqgbgUHodO2 dD7XfzpzvAPxvOW1 X-Received: by 10.107.132.104 with SMTP id g101mr263543iod.181.1494523985827; Thu, 11 May 2017 10:33:05 -0700 (PDT) Subject: Re: [PATCH] x86: Generate PLT relocations for -z now To: "H.J. Lu" Cc: Szabolcs Nagy , Binutils , GNU C Library , nd References: <20170508202153.GA28618@intel.com> <146b87ef-0c8c-c829-18e1-41db38df5fd1@redhat.com> <591431AE.6000201@arm.com> <9b8e44de-2fc0-4946-89d7-01c4528d7518@redhat.com> From: Carlos O'Donell Message-ID: <75a68833-27d1-344b-47aa-7005faac029a@redhat.com> Date: Thu, 11 May 2017 17:33:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-05/txt/msg00348.txt.bz2 On 05/11/2017 01:09 PM, H.J. Lu wrote: > On Thu, May 11, 2017 at 9:44 AM, Carlos O'Donell wrote: >> On 05/11/2017 10:51 AM, H.J. Lu wrote: >>> The run-time R_X86_64_GLOB_DAT relocation against foo is >>> required. There is no need to add another run-time >>> R_X86_64_JUMP_SLOT relocation. We can add a linker option >>> to generate the extra R_X86_64_JUMP_SLOT. But I don't think >>> it should be the default. >> >> I don't disagree with your analysis, I disagree with the execution >> of the plan. >> >> The plan should be: >> >> (a) Analyze uses of the PLT entries. >> >> In this case LD_AUDIT, LD_PROFILE, and ltrace all require them to >> operate correctly. > > As I stated before, glibc and GCC have been doing everything we > can to avoid PLT. > >> (b) Develop plan for migrating developer tooling, like LD_AUDIT, >> which is a part of glibc and is well supported. >> >> (c) Choose one of: >> >> (C.1) Make PLT elision optional e.g. -z noplt >> >> or >> >> (C.2) Make LD_AUDIT work with optimizations. > > This is the only option. Why is this the only option? Is it the only option because we want to reduce the number of dynamic relocs as much as possible? Is it because we have benchmarks that show reducing relocations helps some application? Or is it an abstract engineering decision that a minimum number of relocations is always a good thing? Even though their cost might be hidden in subsequent load/store latencies? If (C.2) is truly the only option, then what are our solutions? (a) Always generate the PLT entries, even if they might be unused. (b) If LD_AUDIT is in effect resolve all R_X86_64_GLOB_DAT which would otherwise have resolved to an STT_FUNC (or equivalent) to the appropriate PLT entry for the function in question. This would bind all such functions to run the profiled resolution function for the lifetime of the process because potentially with -z now, and -z relro this decision is binding once made (and the GOT entries relocated). In (b) how do we find which PLT entry (index) to use for which GOT entry? If we had a 1:1 correspondence then we could make the mapping work. Thoughts? -- Cheers, Carlos.