From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102979 invoked by alias); 28 Mar 2016 17:17:31 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 102966 invoked by uid 89); 28 Mar 2016 17:17:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=groff, Groff, 1328, swift X-HELO: mail-qg0-f51.google.com Received: from mail-qg0-f51.google.com (HELO mail-qg0-f51.google.com) (209.85.192.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 28 Mar 2016 17:17:20 +0000 Received: by mail-qg0-f51.google.com with SMTP id j35so114152759qge.0 for ; Mon, 28 Mar 2016 10:17:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=arl3kzQ53mLjJ8Zl3MOvM2LgKJFO1Sa2NiTjOfFYTGc=; b=UYYfxJjFaE4BOaCVqZgjluhiNNzjx2g4dCjRmhUVM2DJwL/FFV8VEfKd4nQhW1pcn2 CLSefBmxqfpqpM0Cs91u0AVIWUikBbWaOZI24HvTblLebqtIZWLTLGv4hBReSk2+JSAb +9qoWa9IQWjtG91hqtaSf/FXe38lpWNl9RHZMvV3Jb7htregDEx8PlrwC45ch+wEiLuA 7uQSfIIw3Aa9kfu28qjcf6F0wamoceJJ+pKp626jaro9MzPx2bpSVDwnUsHgsiKlNlHT lNiJ/tirQmHmq0DERvRDbAXd74jICo9D/08Y4PMyJH9w6HCKzHO5eyhlcoVemZaxu/z9 LRpA== X-Gm-Message-State: AD7BkJLjlZf1S3QGrmWlyowWQwedCnzyu269c9kXMNhb2unutLn7s9+Gyr8iZFT1mdr1MjmkM0pI/xXKQG/Fag== MIME-Version: 1.0 X-Received: by 10.140.248.8 with SMTP id t8mr5396984qhc.50.1459185437998; Mon, 28 Mar 2016 10:17:17 -0700 (PDT) Received: by 10.55.57.203 with HTTP; Mon, 28 Mar 2016 10:17:17 -0700 (PDT) In-Reply-To: References: <9106B2FB-BB06-413A-A04D-EEFB992784FA@apple.com> <9EFBBDCE-4054-4867-B3E9-9DFE216A234F@apple.com> Date: Mon, 28 Mar 2016 17:17:00 -0000 Message-ID: Subject: Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 From: "H.J. Lu" To: Joe Groff Cc: Cary Coutant , Binutils Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00348.txt.bz2 On Mon, Mar 28, 2016 at 10:01 AM, Joe Groff wrote: > > On Mar 28, 2016, at 5:11 AM, H.J. Lu wrote: > > On Thu, Mar 24, 2016 at 11:31 AM, Cary Coutant wrote: > > What relocation do you propose to access external protected > symbol on x86 for non-PIC code? > > > Non-PIC code can still use a GOT, can't it? > > > Yes. > > > Right. > > Some additional thoughts: > > - This has nothing to do with PIE. Non-PIC-non-PIE code has been > living with this restriction for at least 18 years (since visiblity > was introduced into the gABI). > > - This has nothing to do with Ulrich's diatribe against protected > visibility, which applies only to function symbols (and really only to > one platform, due to how function pointer comparison works). > > > Copy relocation and protected symbol are mutually exclusive. > Since copy relocation is the part of x86 psABIs, it limits > protected symbol effectiveness on x86. In glibc, we add a > local alias to symbol we want to protect and access the local > alias within glibc without GOT. > > > I had thought about doing this as a workaround for us, but if I understand > correctly, this would result in two canonical copies of the object in the That is correct. > process's memory. For what we're using protected symbols for in Swift, we > really want only one canonical object, and would prefer that protected > references from the executable go through a GOT, similar to how references > to external symbols always work in Mach-O. Understood. > - You don't need to go full-on PIC to reference a protected data > symbol in a shared library. You can always statically initialize a > pointer variable, and go indirect through that ("poor-man's PIC"). > > - We could add support for __attribute__((dllimport)) or > __declspec(dllimport) when declaring an external variable that is > expected to be defined in a shared library (ideally, that attribute > ought to be placed in the library's public interface). The compiler > can generate a PIC-style reference for that variable without > penalizing all the other variables in the main program. This is how > HP-UX compilers work on PA and Itanium (using #pragma external). > > > This is a useful feature, similar to -fno-plt, like -fgot, but only on > selective symbols. > > > "protected" is already selective, though. The code generator had to > intentionally set protected visibility on symbols. Compiler needs a way to know if an external symbol is protected or not if we don't want to force to use GOT to access ALL external symbols, even if they turn out to be defined locally at link-time. > > - Compilers could also generate tentative PIC-style references, with > sufficient relocations to allow the linker to convert the indirect > reference to a direct reference when possible (changing the second > load into a nop or copy). HP-UX also does this. > > > I extended the x86 psABIs with relaxable GOT relocations and > implemented the similar linker optimization in ld in binutils 2.26 > and gold also implemented the subset of the linker optimization. > > - Indirect references from PIC code to a protected symbol penalize the > common case (referencing a symbol within its own module) to support > the uncommon case, while introducing the nasty side effects of a COPY > relocation. > > - COPY relocations are evil. They bind an application to a specific > version of a shared library's ABI, and introduce a hidden startup > cost. If we're going to make any changes, we should be moving towards > elimination of COPY relocations, rather than disabling features that > were designed to improve performance. > > > Copy relocation can improve performance. Google enabled copy > relocations for PIE in ld/gold and GCC to improve prefomance by > up to 5%: > > https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01215.html > > It is in GCC 5. > > > Did you look at what the costs were in startup time and dirty pages by using No, I haven't. It will be a very useful data. > copy relocations? What do you do if the size of the definition changes in a > new version of the library? > The size of sys_errlist data symbol in glibc changed over time. We use symbol versioning to provide backward binary compatibility: 1326: 001c7a80 492 OBJECT GLOBAL DEFAULT 29 sys_errlist@GLIBC_2.0 1327: 001c7a80 500 OBJECT GLOBAL DEFAULT 29 sys_errlist@GLIBC_2.1 1324: 001c7a80 540 OBJECT GLOBAL DEFAULT 29 sys_errlist@@GLIBC_2.12 1328: 001c7a80 504 OBJECT GLOBAL DEFAULT 29 sys_errlist@GLIBC_2.3 1330: 001c7a80 528 OBJECT GLOBAL DEFAULT 29 sys_errlist@GLIBC_2.4 -- H.J.