From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1839 invoked by alias); 29 Mar 2016 19:36:39 -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 920 invoked by uid 89); 29 Mar 2016 19:36:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=refuse, jgroffapplecom, jgroff@apple.com, price X-HELO: mail-in2.apple.com Received: from mail-out2.apple.com (HELO mail-in2.apple.com) (17.151.62.25) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 29 Mar 2016 19:36:31 +0000 Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id E5.A0.06427.D39DAF65; Tue, 29 Mar 2016 12:36:29 -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 64.E8.18091.D39DAF65; Tue, 29 Mar 2016 12:36:29 -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 <0O4T00BKWFSS6610@nwk-mmpp-sz13.apple.com> for binutils@sourceware.org; Tue, 29 Mar 2016 12:36:29 -0700 (PDT) Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 From: Joe Groff In-reply-to: Date: Tue, 29 Mar 2016 19:36:00 -0000 Cc: Alan Modra , Cary Coutant , Binutils Content-transfer-encoding: quoted-printable Message-id: <983472E1-A1BC-4970-9CF9-0138A6BAD16D@apple.com> References: To: "H.J. Lu" X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00393.txt.bz2 > On Mar 29, 2016, at 12:33 PM, H.J. Lu wrote: >=20 > On Tue, Mar 29, 2016 at 12:31 PM, Joe Groff wrote: >> 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 page= s by using >>>>>>>> copy relocations? What do you do if the size of the definition cha= nges in a >>>>>>>> new version of the library? >>>>>>>=20 >>>>>>> There wouldn't be a measurable cost in dirty pages; the copied obje= cts >>>>>>> are simply allocated in bss in the executable. >>>>>>=20 >>>>>> Wouldn't references to the symbol from within the .so need to be rel= ocated 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 updat= ed >>> 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 propo= sed >>> to mark the object as such so that we won't get surprise at run-time. >>=20 >> I think what Cary's arguing (and I honestly would expect) is that copyin= g the protected symbol *is* for all intents and purposes a preemption. I'd = expect copy relocations against protected symbols to be linker errors. I gu= ess what's missing for gcc's intended optimization is an indication to the = compiler that a symbol is protected in its home library, to suppress emitti= ng PC-relative references to a copy relocation. >=20 > That is what I meant by "That is why I proposed to mark the object as suc= h so > that we won't get surprise at run-time." I don't see why it would be a runtime failure. ld could refuse to resolve t= he relocation at static link time, couldn't it? -Joe