From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75850 invoked by alias); 18 Apr 2016 19:28:40 -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 75829 invoked by uid 89); 18 Apr 2016 19:28:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-qg0-f54.google.com Received: from mail-qg0-f54.google.com (HELO mail-qg0-f54.google.com) (209.85.192.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 18 Apr 2016 19:28:29 +0000 Received: by mail-qg0-f54.google.com with SMTP id f74so2052311qge.2 for ; Mon, 18 Apr 2016 12:28:29 -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=htT8UtIbtxdUBEHlDXD+rD30mYqaGZDmjmMO+i3q3l4=; b=jlQqgGAsSlNLG7g98YSVePHpjdVycroaQzvbcQL/8Cl6ISgKXm5bicwV+O1svUMQLQ LBLYGEP0qSCmZSXnFkodpNs8c/IpPfQrYLgr9sPO/n01s5wUqO006KTlXUkN2B9YIzkc Qrg7HplI/NTgUPf9VOhea0MLwQuy4DBUPec5t1iKN++pMK1/ls1NzIGBJk1QOuS7S+K7 8bcpdlwF4e3kcslmD0lwckj1t75WfZ94QTAR/g633eueSzAxMM8PO9tXM+Aev/p2Ft2B BhxVlJoqndSIk6BAeCuMEs3eg5CoZ+BSlYTL1otRPKvxj/Da2/hTtMffo3CzyKxRMKRR aYlA== X-Gm-Message-State: AOPr4FXC+Ex0FJ9+gJ3n++8IOY48ptEda4Bh5G2Jc9nSAyH6i2NWbHMiR1HaR5VEFudQxS9rI+VQaZTy74E1IQ== MIME-Version: 1.0 X-Received: by 10.55.11.4 with SMTP id 4mr23739788qkl.92.1461007707986; Mon, 18 Apr 2016 12:28:27 -0700 (PDT) Received: by 10.55.217.134 with HTTP; Mon, 18 Apr 2016 12:28:27 -0700 (PDT) In-Reply-To: <20160418185151.GL2920@laptop.zalov.cz> References: <20160330143421.GM15812@bubble.grove.modra.org> <571161D0.10601@redhat.com> <20160418144911.GG15088@bubble.grove.modra.org> <20160418185151.GL2920@laptop.zalov.cz> Date: Mon, 18 Apr 2016 19:28: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: Jakub Jelinek Cc: Michael Matz , "Maciej W. Rozycki" , Alan Modra , Richard Biener , Jeff Law , Cary Coutant , Joe Groff , Binutils , GCC Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00284.txt.bz2 On Mon, Apr 18, 2016 at 11:51 AM, Jakub Jelinek wrote: > 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. > It is a good idea to revisit the whole protected visibility issue on x86 in terms of C/C++ languages, x86 psABIs, compiler, ld and ld.so. -- H.J.