From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39589 invoked by alias); 29 Mar 2016 22:05:03 -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 39536 invoked by uid 89); 29 Mar 2016 22:05:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=clients X-HELO: mail-qk0-f179.google.com Received: from mail-qk0-f179.google.com (HELO mail-qk0-f179.google.com) (209.85.220.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 29 Mar 2016 22:04:57 +0000 Received: by mail-qk0-f179.google.com with SMTP id o6so12326660qkc.2 for ; Tue, 29 Mar 2016 15:04:57 -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=qDcnsN25MVjCy4E3hK3rqoyvne6U0DDqIyVQsOIZ9zA=; b=kXcpYdwsfsCNkdby/blfylExpbQ/1WkczbzmzrO2R9UXIZD1tFnFl/p3BppwZBNk/A M+CHX8eXgfSiWMfE7FNgyxT9drftxXaR4VTLZSDaum6eHIcgVo9dgVfrJJw/7nDryba+ HKHraKJkhDj+MhsR1l04nH0jSfX5GQl5qBFvZ5+zPZ5pSvaXCcQ5cTxkPUdYslufJ6aQ E9VDJHFQTuXjcOmu2TNQfQ0Hg4pA13xk0GljJcVF134SXwPJ67Iw7oC8nhPu9folRcXx IaCm2aHgIMt4sIBBEhlvmeuuqlAT8UvJi+qr/KVI0ejTtOqScL/mBGkrCBy1XupfxW6e mi8w== X-Gm-Message-State: AD7BkJKch6k4sjijDirErBA+3NffF5C+WV3JhkT40rU3OGBNZMEdpf/VdxO3UKU6kudbdPO923ZlVgCCg5F6RA== MIME-Version: 1.0 X-Received: by 10.55.27.42 with SMTP id b42mr5858828qkb.51.1459289095810; Tue, 29 Mar 2016 15:04:55 -0700 (PDT) Received: by 10.55.57.203 with HTTP; Tue, 29 Mar 2016 15:04:55 -0700 (PDT) In-Reply-To: References: <983472E1-A1BC-4970-9CF9-0138A6BAD16D@apple.com> <6AAD87D2-90F9-4AD7-A195-AC91B76EA6AE@apple.com> Date: Tue, 29 Mar 2016 22:05: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/msg00397.txt.bz2 On Tue, Mar 29, 2016 at 12:54 PM, H.J. Lu wrote: > On Tue, Mar 29, 2016 at 12:51 PM, Joe Groff wrote: >> >>> On Mar 29, 2016, at 12:43 PM, H.J. Lu wrote: >>> >>> 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 disall= ow >>> copy relocation against protected symbol at link-time. >> >> However, protected doesn't work this way in older binutils, or with alte= rnative tools like llvm or gold, and it sounds like protected was never int= ended to work this way either. Rather If gcc is interested in pursuing this= optimization, it seems more responsible to me they could investigate intro= ducing language-level annotations that let libraries opt into the optimizat= ion, instead of unilaterally breaking things for other binutils clients and= introducing new complexity to get back to the original behavior. >> > > Protected symbol never worked correctly on x86 before. My > change closed a few long-standing bugs. There is no going-back. If you want to avoid copy relocation, you can do 1. Pass -z noextern-protected-data to build the shared object. 2. Use GOT to access external data in executable. H.J.