From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29042 invoked by alias); 29 Mar 2016 19:43:50 -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 29032 invoked by uid 89); 29 Mar 2016 19:43:49 -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=price, paid, his, surprise X-HELO: mail-qg0-f48.google.com Received: from mail-qg0-f48.google.com (HELO mail-qg0-f48.google.com) (209.85.192.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 29 Mar 2016 19:43:47 +0000 Received: by mail-qg0-f48.google.com with SMTP id w104so15775894qge.3 for ; Tue, 29 Mar 2016 12:43:47 -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:content-transfer-encoding; bh=xnXorz7xWe22I8bjsoQd4f6rjKVbsWfmuZ8/ZYHT0EI=; b=V69hrXIIgtLG4z2JRD4FX7rUT0iRw2eRtAYw60aPQ55qpbAdy+kAJw4a++s6OL6c8D zvDmAJ5RR2vKarVZNPEkvESnTRpjhdywg3zKi6SNsnBIBjf89bzxA3Vvi6DOzEjtXzMR EbjjHHGhXyJ9S5fT4rya7jd0Ld6BRPqqVD+0SQ7B27161Q6P4P07Wlpsi8ty2Fbq3shQ Fq7m17czACtM6R5v0WANsnJoWEPZpiV+4v+DvffN9JyTC1E5x9s7pVwLpXW63M4NFGkO StGAWo5Tno641sd3xlt3BVHckiKWuEJ3NvHRJb7XdTKIspisXozkaGwHRKLLakYYRpNt 6FYQ== X-Gm-Message-State: AD7BkJLUrfUZtGcTqqrQP162EWC5b1MUvNJawxeo9SQQMI6s4XI2Qrd4XcUimvpnu58/A/f3PB7z3D08P/BVKA== MIME-Version: 1.0 X-Received: by 10.141.5.137 with SMTP id h131mr5360490qhd.47.1459280625776; Tue, 29 Mar 2016 12:43:45 -0700 (PDT) Received: by 10.55.57.203 with HTTP; Tue, 29 Mar 2016 12:43:45 -0700 (PDT) In-Reply-To: <983472E1-A1BC-4970-9CF9-0138A6BAD16D@apple.com> References: <983472E1-A1BC-4970-9CF9-0138A6BAD16D@apple.com> Date: Tue, 29 Mar 2016 19:43:00 -0000 Message-ID: Subject: Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 From: "H.J. Lu" To: Joe Groff Cc: Alan Modra , Cary Coutant , Binutils Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00394.txt.bz2 On Tue, Mar 29, 2016 at 12:36 PM, Joe Groff wrote: > >> On Mar 29, 2016, at 12:33 PM, H.J. Lu wrote: >> >> On Tue, Mar 29, 2016 at 12:31 PM, Joe Groff wrote: >>> On Mar 29, 2016, at 8:44 AM, H.J. Lu wrote: >>>> >>>> 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 pag= es by using >>>>>>>>> copy relocations? What do you do if the size of the definition ch= anges in a >>>>>>>>> new version of the library? >>>>>>>> >>>>>>>> There wouldn't be a measurable cost in dirty pages; the copied obj= ects >>>>>>>> are simply allocated in bss in the executable. >>>>>>> >>>>>>> Wouldn't references to the symbol from within the .so need to be re= located 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. >>>>> >>>> >>>> As I said before, copy relocation and protected symbol are fundamental= ly >>>> incompatible. Since copy relocation is the part of x86 psABIs, I upda= ted >>>> GCC, glibc and ld to make protected symbol to work with copy relocatio= n. >>>> 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 co= py >>>> relocation in executable, which is a psABI change. That is why I prop= osed >>>> 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 copyi= ng the protected symbol *is* for all intents and purposes a preemption. I'd= expect copy relocations against protected symbols to be linker errors. I g= uess 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 emitt= ing PC-relative references to a copy relocation. >> >> That is what I meant by "That is why I proposed to mark the object as su= ch 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= the relocation at static link time, couldn't it? > The link-time shared library may be very different from the run-time shared library. Since copy relocation works correctly against protected symbol with the current gcc, binutils and glibc, we can't simply disallow copy relocation against protected symbol at link-time. It should be done with a link command-line as well as markers on the input files. --=20 H.J.