From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53764 invoked by alias); 18 Apr 2016 17:55:44 -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 53730 invoked by uid 89); 18 Apr 2016 17:55:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=yield, Hx-languages-length:1808, survive X-HELO: mail-io0-f178.google.com Received: from mail-io0-f178.google.com (HELO mail-io0-f178.google.com) (209.85.223.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 18 Apr 2016 17:55:37 +0000 Received: by mail-io0-f178.google.com with SMTP id o126so202398392iod.0 for ; Mon, 18 Apr 2016 10:55:37 -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=BUZGHMYOpmD6UE33Q5AyWZr4swfZxIi0cvbsao5loWk=; b=lj73OhGmgwFzHhF2p10oQuRyg2hi9kBvmPOhKC3e/AYPcVvk8mnvfJjiyKKKJIgxrX 7qP8VNkuqbjUd09aZC90kwmWTnz9czTZgu4Vd5DuXXl/JjRtppyGChW0w9qjQobK7s+X wW+S6sj49H6+XEhxGPb7D15FXryG7TDE15L0fMdSph9EkgbQKgUC5x3cbE7TDQchE51V IawtVLz2ZtngAGSqoamWMtt47AjrwkijKtUrUYfuEeYoQzBBKvQrF5lX2PPBkjMwrZfe bh1Vu50ct6wSE1+9qChB8M1fww4Nslth6mY3ioVE2qq8Y9Vtolv5pa5E5xdo+oF2IMld AEJA== X-Gm-Message-State: AOPr4FWeS2pQoFf5IDNODCmuGI6LyuWt12BF+hwZxcsgn2dsLdMHUjieF5n1t4PIImJfJgVOoVeiF3yRXge4jQ== MIME-Version: 1.0 X-Received: by 10.107.31.129 with SMTP id f123mr38319391iof.180.1461002135345; Mon, 18 Apr 2016 10:55:35 -0700 (PDT) Received: by 10.36.50.22 with HTTP; Mon, 18 Apr 2016 10:55:35 -0700 (PDT) In-Reply-To: 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> Date: Mon, 18 Apr 2016 17:55: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: Cary Coutant To: Michael Matz Cc: "H.J. Lu" , "Maciej W. Rozycki" , Alan Modra , Richard Biener , Jeff Law , Joe Groff , Binutils , GCC Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00280.txt.bz2 >> 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. > 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. Function pointer comparison is also a mess, and is the only reason why the treatment for protected function symbols is so complicated. It all boils down the the language guarantees that (a) the address of a function must be unique, (b) that the address of a given function must always be the same value, and (c) that these guarantees survive a conversion to void*. I'd argue that all of these language guarantees are poor choices. Just like constant strings, which are allowed to be pooled, two identical functions ought to be allowed to be pooled (folded). If function pointer comparison were restricted to function pointer types, we could allow the address of a function to yield the address of a PLT entry, and use a deep comparison to decide whether two unequal function pointers were in fact equivalent. But that's another topic for another day. -cary