From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 123860 invoked by alias); 25 Apr 2016 17:24:16 -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 123841 invoked by uid 89); 25 Apr 2016 17:24:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=damn, HTo:U*ccoutant, guiding, HTo:U*matz X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 25 Apr 2016 17:24:15 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E761B62645; Mon, 25 Apr 2016 17:24:13 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-93.phx2.redhat.com [10.3.113.93]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3PHOCFj020698; Mon, 25 Apr 2016 13:24:12 -0400 Subject: Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248] To: Cary Coutant , Michael Matz 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> Cc: "H.J. Lu" , "Maciej W. Rozycki" , Alan Modra , Richard Biener , Joe Groff , Binutils , GCC From: Jeff Law Message-ID: <18662de1-62db-2b44-ef50-2c04204e2521@redhat.com> Date: Mon, 25 Apr 2016 17:24:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00417.txt.bz2 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. Jeff