From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114992 invoked by alias); 29 Mar 2016 19:31:43 -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 114972 invoked by uid 89); 29 Mar 2016 19:31:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=amodragmailcom, amodra@gmail.com, price, paid X-HELO: mail-in4.apple.com Received: from mail-out4.apple.com (HELO mail-in4.apple.com) (17.151.62.26) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 29 Mar 2016 19:31:41 +0000 Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id BD.5B.21445.B18DAF65; Tue, 29 Mar 2016 12:31:39 -0700 (PDT) Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id CB.34.18091.A18DAF65; Tue, 29 Mar 2016 12:31:38 -0700 (PDT) Received: from [17.153.78.77] by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O4T0065ZFJ3YD40@nwk-mmpp-sz13.apple.com> for binutils@sourceware.org; Tue, 29 Mar 2016 12:31:38 -0700 (PDT) Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Fwd: Preventing preemption of 'protected' symbols in GNU ld 2.26 From: Joe Groff Date: Tue, 29 Mar 2016 19:31:00 -0000 Cc: Alan Modra , Cary Coutant , Binutils Content-transfer-encoding: quoted-printable Message-id: References: To: "H.J. Lu" X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00391.txt.bz2 On Mar 29, 2016, at 8:44 AM, H.J. Lu wrote: >=20 > On Mon, Mar 28, 2016 at 4:21 PM, Alan Modra wrote: >> On Mon, Mar 28, 2016 at 03:38:01PM -0700, Cary Coutant wrote: >>>>>> Did you look at what the costs were in startup time and dirty pages = by using >>>>>> copy relocations? What do you do if the size of the definition chang= es in a >>>>>> new version of the library? >>>>>=20 >>>>> There wouldn't be a measurable cost in dirty pages; the copied objects >>>>> are simply allocated in bss in the executable. >>>>=20 >>>> Wouldn't references to the symbol from within the .so need to be reloc= ated to reference the now-canonical copy in the executable? >>>=20 >>> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> Apparently most people in the gcc and glibc communities saw these >> toolchain modifications as fiendishly clever. >>=20 >=20 > As I said before, copy relocation and protected symbol are fundamentally > incompatible. Since copy relocation is the part of x86 psABIs, I updated > GCC, glibc and ld to make protected symbol to work with copy relocation. > That is protected symbol may be external, but won't be preempted. The > price I paid is that protected symbol won't be accessed via PC-relative > relocation within the shared object. To access protected symbol via > PC-relative relocation within the shared object, we need to disable copy > relocation in executable, which is a psABI change. That is why I proposed > to mark the object as such so that we won't get surprise at run-time. I think what Cary's arguing (and I honestly would expect) is that copying t= he protected symbol *is* for all intents and purposes a preemption. I'd exp= ect copy relocations against protected symbols to be linker errors. I guess= what's missing for gcc's intended optimization is an indication to the com= piler that a symbol is protected in its home library, to suppress emitting = PC-relative references to a copy relocation. -Joe