From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54142 invoked by alias); 18 Apr 2016 17:24:02 -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 53998 invoked by uid 89); 18 Apr 2016 17:24:01 -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,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=unavailable version=3.3.2 spammy= X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Mon, 18 Apr 2016 17:23:59 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id DBA31AC28; Mon, 18 Apr 2016 17:23:53 +0000 (UTC) Date: Mon, 18 Apr 2016 17:24:00 -0000 From: Michael Matz To: "H.J. Lu" cc: "Maciej W. Rozycki" , Alan Modra , Richard Biener , Jeff Law , Cary Coutant , Joe Groff , Binutils , GCC Subject: Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248] In-Reply-To: Message-ID: 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> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00278.txt.bz2 Hi, On Mon, 18 Apr 2016, H.J. Lu wrote: > > reason is DSO code (also handcoded assembly) may reasonably expect to > > be able to load the address with a PC-relative load-address type > > instruction (ADDIUPC, LEA, MOVAB, etc.) and the target may not even > > have suitable dynamic relocations available to apply any load-time > > fixup if the symbol referred turns up outside of the DSO. The > > instruction used may have a PC-relative range limit too. > > 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. E.g. one limitation might very well be that function pointer comparison for protected functions doesn't work (gives different outcomes if the pointer is built from inside the exe or from a shared lib). (No matter how it's built, it will still _work_ when called). Alternatively we can make comparison work (by using the exe PLT slot), in which case Alans testcase will need more complications to show that protected visibility currently is broken. Alans testcase will work right now (as in showing protected being broken) on data symbols. Ciao, Michael.