From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111222 invoked by alias); 29 Mar 2016 00:29:52 -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 111211 invoked by uid 89); 29 Mar 2016 00:29:51 -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=sri, exceedingly, his, communities X-HELO: mail-ig0-f169.google.com Received: from mail-ig0-f169.google.com (HELO mail-ig0-f169.google.com) (209.85.213.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 29 Mar 2016 00:29:49 +0000 Received: by mail-ig0-f169.google.com with SMTP id m10so1802505igt.1 for ; Mon, 28 Mar 2016 17:29:49 -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=rRZgZ07O28d0laF4jprPjttGlVexbHwW03VCEgaLQXg=; b=c0abhCvhrLT5KYLdcr/8ZVBUvV9kt/RUuEVdz3JLSVdCiouNk51TTGl6oz11UAHdyx Qpes7JpaSjB1KDW42Pl5i8zjzqnO8cW9acHkJOYlb70ysA+GtYdOBKhvfGFfPCk+3rYN baLNvct9QVicH6YaXKNqe7k/yAnaT6gG5NGkjt7VO5nY7y37SC7s5wknnLetqagQk5Q2 BNdJJPIw3jCl5ZV30u46lP6J3uDnubaYPTcxzbx2OC5jGtUoHOi/kXEpssy/CrwcZk6U AteeulnnK1Z7+Jv4RXbwwrcMZXFpiP1sqCu8vr5xE5VbhQp2I3+swnhNPcAeUG1xNeVf oa+Q== X-Gm-Message-State: AD7BkJJMnKHakaqTizZoh+Lwy81YkKZGKOeiHUQ467QLkQPX3nh3rGZJ67weuIuX7IeUzdEMMUp2Eq9qRp5ilg== MIME-Version: 1.0 X-Received: by 10.50.97.70 with SMTP id dy6mr8841031igb.73.1459211387814; Mon, 28 Mar 2016 17:29:47 -0700 (PDT) Received: by 10.36.200.8 with HTTP; Mon, 28 Mar 2016 17:29:47 -0700 (PDT) In-Reply-To: <20160328232105.GA15812@bubble.grove.modra.org> References: <9EFBBDCE-4054-4867-B3E9-9DFE216A234F@apple.com> <08556ECF-C47B-400E-91A2-56D338E55D86@apple.com> <20160328232105.GA15812@bubble.grove.modra.org> Date: Tue, 29 Mar 2016 00:29:00 -0000 Message-ID: Subject: Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 From: Cary Coutant To: Alan Modra Cc: Joe Groff , "H.J. Lu" , Binutils Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00359.txt.bz2 >> > Wouldn't references to the symbol from within the .so need to be relocated to reference the now-canonical copy in the executable? >> >> No, references from within the .so would have always used the GOT. >> Non-protected global symbols in a shared library are still >> pre-emptible, so they are always indirect, and there's always a >> dynamic relocation for the GOT entry. Whether the prevailing >> definition winds up in the executable or the shared library, the >> dynamic loader still has to bind the symbol and apply the relocation. > > HJ's changes to protected visibility meant compiler changes so that > protected visibility in shared libraries is no longer seen as local. > So yes, protected visibility symbols in shared libraries now go > through the GOT. Prior to his changes, they were optimized to a > pc-relative access. Joe is correct in pointing out that shared > libraries needed a change. Bad luck if you're using an older > compiler. Also bad luck if you want to use protected visibility to > optimize your shared library. > > HJ also made glibc ld.so changes to ensure the semantics of protected > visibility symbols remain unchanged when multiple shared libraries > define the same protected visibility symbol. > > Apparently most people in the gcc and glibc communities saw these > toolchain modifications as fiendishly clever. I may have misunderstood the context of Joe's question, but I read it as asking about the effect of Sri's changes to use direct references to all symbols in PIE mode, rather than the effect of HJ's changes to use indirect references to protected symbols in PIC mode. In the former context, we're talking about code where protected symbols are not often used, references from the executable to shared library data is infrequent, and the intersection of the two is exceedingly rare. There was a clear benefit to changing PIE code to use GOT-relative, rather than GOT-indirect, references to data. It was only necessary to tweak the linker to allow COPY relocations from a PIE executable so that the infrequent references from the executable to (non-protected) shared library data symbols would still work. Any non-PIC references to protected symbols would have already failed because the code had already successfully built as a non-PIE application. In the latter context, we're talking about penalizing access to protected symbols within a shared library in order to support that exceedingly rare case that already didn't work for non-PIE code. I just don't see the value. It's too bad that Sri's PIE changes pre-dated HJ's mov-to-lea link-time optimization. I suspect that that optimization, all by itself, would have reclaimed most of the lost performance that Sri observed when turning on -fPIE, and we may never have descended into this morass. -cary