From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7895 invoked by alias); 18 Apr 2016 18:52:32 -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 7819 invoked by uid 89); 18 Apr 2016 18:52:32 -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=H*Ad:U*matz, Hx-languages-length:2536 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, 18 Apr 2016 18:52:11 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (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 B7772811A2; Mon, 18 Apr 2016 18:52:09 +0000 (UTC) Received: from laptop.zalov.cz (ovpn-116-117.ams2.redhat.com [10.36.116.117]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3IIq6UR006783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Apr 2016 14:52:08 -0400 Received: from laptop.zalov.cz (localhost [127.0.0.1]) by laptop.zalov.cz (8.15.2/8.15.2) with ESMTP id u3IIq1LW015700; Mon, 18 Apr 2016 20:52:02 +0200 Received: (from jakub@localhost) by laptop.zalov.cz (8.15.2/8.15.2/Submit) id u3IIprB7015699; Mon, 18 Apr 2016 20:51:53 +0200 Date: Mon, 18 Apr 2016 18:52:00 -0000 From: Jakub Jelinek To: "H.J. Lu" Cc: Michael Matz , "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] Message-ID: <20160418185151.GL2920@laptop.zalov.cz> Reply-To: Jakub Jelinek References: <20160330143421.GM15812@bubble.grove.modra.org> <571161D0.10601@redhat.com> <20160418144911.GG15088@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2016-04/txt/msg00282.txt.bz2 On Mon, Apr 18, 2016 at 10:27:45AM -0700, H.J. Lu wrote: > On Mon, Apr 18, 2016 at 10:23 AM, Michael Matz wrote: > > 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. > > > > We have special treatment for pointer of protected function symbol > in ld and ld.so from day one, which, BTW, disables optimization of > pointer of protected function symbol inside the shared library. But maybe that is the mistake. Doing this makes protected visibility no longer a userful optimization for anything, it is usually more expensive than normal visibility, so it is generally a pessimization nobody should really use. Compared to this, having a protected-like visibility which doesn't care about function pointer comparisons would be generally useful to many projects, and e.g. glibc is heavily using it itself (using hacked up macros). Generally it could be even implementable just on the compiler side and leave the badly designed "protected" to keep what it used to do (i.e. revert the change) and hope or actively suggest to users that if they ever think of this "protected" visibility, they are always doing something wrong. Jakub