From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15615 invoked by alias); 25 Apr 2016 17:31:54 -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 15558 invoked by uid 89); 25 Apr 2016 17:31:54 -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=H*Ad:U*ccoutant, link-time, linktime, HTo:U*law X-HELO: mail-qk0-f181.google.com Received: from mail-qk0-f181.google.com (HELO mail-qk0-f181.google.com) (209.85.220.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 25 Apr 2016 17:31:53 +0000 Received: by mail-qk0-f181.google.com with SMTP id x7so65598448qkd.3 for ; Mon, 25 Apr 2016 10:31:52 -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; bh=Tx+WXgnIyoiXlvzFMn/1bqVs/2pdyUT/wYV7NIjKzSY=; b=Co9RLkIUKJ3t9JipgPjxsNmcfaLeKgWnMpzpchCxDb8HFY++TQKu9WPzoiLYloGBjj 3LfYJ9U/V+KTaRBehUtA0q0wV6Jf6HgHe5lhCVdVaam6XQ8qoiXFLZxroz1gaLTM2PkP 3V3XCj8pP9i8qi29MuAWHup8an+i7fO+4ejKU2xvAXA0+8UohpwAaxu6RYBOAjItEy1r VhIveTcQ3yK4F7FnpZXOabn82Jpmt+3rwmy6fkkp4z4viJKSo32XMQnBRQSZ+8Rt7zNU Ghor6E+YKYYn5X2wc59yKgDEwI1O+3ucjxEKJl9cuSg9x0LR0LajrKp/G7ZsTpeiqyOc jxZA== X-Gm-Message-State: AOPr4FWBef0KKDOU6GbyOsrb7VrCWCsIHWILeKT0QGxgmlw1eJcaKIZmPet0tUBdCHZnSCAp4ywiEqRvaEh2Lw== MIME-Version: 1.0 X-Received: by 10.55.146.199 with SMTP id u190mr19804974qkd.174.1461605510942; Mon, 25 Apr 2016 10:31:50 -0700 (PDT) Received: by 10.55.217.134 with HTTP; Mon, 25 Apr 2016 10:31:50 -0700 (PDT) In-Reply-To: <18662de1-62db-2b44-ef50-2c04204e2521@redhat.com> References: <983472E1-A1BC-4970-9CF9-0138A6BAD16D@apple.com> <6AAD87D2-90F9-4AD7-A195-AC91B76EA6AE@apple.com> <56FB5061.9010303@redhat.com> <20160330143421.GM15812@bubble.grove.modra.org> <571161D0.10601@redhat.com> <20160418144911.GG15088@bubble.grove.modra.org> <18662de1-62db-2b44-ef50-2c04204e2521@redhat.com> Date: Mon, 25 Apr 2016 17:31:00 -0000 Message-ID: Subject: Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248] From: "H.J. Lu" To: Jeff Law Cc: Cary Coutant , Michael Matz , "Maciej W. Rozycki" , Alan Modra , Richard Biener , Joe Groff , Binutils , GCC Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00418.txt.bz2 On Mon, Apr 25, 2016 at 10:24 AM, Jeff Law wrote: > On 04/18/2016 11:55 AM, Cary Coutant wrote: >>>> >>>> That is why protected visibility is such a mess. >>> >>> >>> Not mess, but it comes with certain limitations. And that's okay. It's >>> intended as an optimization, and it should do that optimization if >>> requested, and error out if it can't be done for whatever reason. >> >> >> I completely agree. > > ISTM this ought to be the guiding principle here, with the additional caveat > that if one of the limitations is tickled that we issue a good diagnostic. > > The current situation (gcc-5, gcc-6-rc) essentially de-optimizes protected > systems in an attempt to work around the various limitations of protected > symbols. Reverting that change is, IMHO, what needs to happen. My worry is > that we're so damn late in the gcc-6 cycle that it may need to be deferred > to 6.2 or beyond. Please keep in mind that many limitations can only be detected at link-time or run-time, which are yet to be implemented, not at compile-time. -- H.J.