From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8602 invoked by alias); 28 Mar 2016 22:24:58 -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 8582 invoked by uid 89); 28 Mar 2016 22:24:57 -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=Hx-languages-length:1323 X-HELO: mail-in7.apple.com Received: from mail-out7.apple.com (HELO mail-in7.apple.com) (17.151.62.29) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 28 Mar 2016 22:24:56 +0000 Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id C8.7F.25552.63FA9F65; Mon, 28 Mar 2016 15:24:54 -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 A1.86.18091.63FA9F65; Mon, 28 Mar 2016 15:24:54 -0700 (PDT) Received: from [17.114.73.8] by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O4R00JHNSXHKK40@nwk-mmpp-sz13.apple.com> for binutils@sourceware.org; Mon, 28 Mar 2016 15:24:54 -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: Mon, 28 Mar 2016 22:24:00 -0000 Cc: "H.J. Lu" , Binutils Content-transfer-encoding: quoted-printable Message-id: <08556ECF-C47B-400E-91A2-56D338E55D86@apple.com> References: <9106B2FB-BB06-413A-A04D-EEFB992784FA@apple.com> <9EFBBDCE-4054-4867-B3E9-9DFE216A234F@apple.com> To: Cary Coutant X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00351.txt.bz2 > On Mar 28, 2016, at 3:21 PM, Cary Coutant wrote: >=20 >> Did you look at what the costs were in startup time and dirty pages by u= sing >> copy relocations? What do you do if the size of the definition changes i= n 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. Wouldn't references to the symbol from within the .so need to be relocated = to reference the now-canonical copy in the executable? -Joe >=20 > Startup time wasn't a concern either, simply because COPY relocations > weren't the real issue. We had to support an *occasional* COPY > relocation in order to enable -fPIE to access globals directly rather > than through the GOT. These would be the same COPY relocations that > the apps would have already been using in non-PIE mode (things like > stdin, stdout, and stderr, e.g.). >=20 > The size of an object is baked into the ABI when a COPY relocation is > used, so any change in size is an ABI change (often handled, as HJ > pointed out, with versioning). For a lot of common COPY relocations, > that's not really an issue, because both the size and the layout are > baked in through macros like putc() and getc(). >=20 > -cary