From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80941 invoked by alias); 30 Mar 2016 04:04:56 -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 80893 invoked by uid 89); 30 Mar 2016 04:04:53 -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=buried, Hx-languages-length:1968, clients 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; Wed, 30 Mar 2016 04:04:51 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 92B24C049E1D; Wed, 30 Mar 2016 04:04:50 +0000 (UTC) Received: from slagheap.utah.redhat.com (ovpn-113-52.phx2.redhat.com [10.3.113.52]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2U44o52012302; Wed, 30 Mar 2016 00:04:50 -0400 Subject: Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 To: Cary Coutant , "H.J. Lu" References: <983472E1-A1BC-4970-9CF9-0138A6BAD16D@apple.com> <6AAD87D2-90F9-4AD7-A195-AC91B76EA6AE@apple.com> Cc: Joe Groff , Alan Modra , Binutils From: Jeff Law Message-ID: <56FB5061.9010303@redhat.com> Date: Wed, 30 Mar 2016 04:04:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.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-03/txt/msg00408.txt.bz2 On 03/29/2016 07:46 PM, Cary Coutant wrote: >>> However, protected doesn't work this way in older binutils, or with alternative tools like llvm or gold, and it sounds like protected was never intended to work this way either. Rather If gcc is interested in pursuing this optimization, it seems more responsible to me they could investigate introducing language-level annotations that let libraries opt into the optimization, 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. > > You keep countering my arguments with assertions like, "it was a bug > and I fixed it," but you present no arguments of your own to support > your position. I'm not sure what long-standing bugs you're referring > to -- the only one I can find, PR target/65248 [1], was filed by you > yourself, so you can't really use that as support. In fact, PR > ld/15228 [2], was filed against ld for *not* refusing to make a COPY > relocation to a protected symbol, and Alan fixed that. Gold has the > same bug, and I intend to fix it there, too. And FWIW, there are some folks on the GCC side of things that think that HJ's change for 65248 is broken and needs to be reverted before gcc-6 releases. I'm not familiar enough with all the issues, but I am familiar enough with the work of HJ, Alan and yourself that if you & Alan say HJ's GCC change is wrong, then, well, it's wrong and needs to be reverted. It would help me immensely on the GCC side if things if you and Alan could easily summarize correct behavior and the impact if we were to just revert HJ's change. A testcase would be amazingly helpful too. I'm sure I could extract the relevant info out of the thread, but I'm just buried right now. jeff