From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110832 invoked by alias); 19 Apr 2016 15:46:42 -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 110810 invoked by uid 89); 19 Apr 2016 15:46:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=suit, Hx-languages-length:2605, concepts X-HELO: mail-pa0-f48.google.com Received: from mail-pa0-f48.google.com (HELO mail-pa0-f48.google.com) (209.85.220.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 19 Apr 2016 15:46:25 +0000 Received: by mail-pa0-f48.google.com with SMTP id fs9so7869385pac.2 for ; Tue, 19 Apr 2016 08:46:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=tKCeOhAxxvvmoKJwHEcIYJgr/ewWmGzJU14PPUMZJrA=; b=EtjA6yLqSvaKFvJWwBT6QDi3E5jHwqyY8QyCFpidhUd3b5o6WA2c1+xNHd63uBLuvu 8NO63NW/OhbGJKQRCfpzmG3PI6O/Gf1+7WFoL3DEyZ321hc07oO8aOrzyVGrhSfc2PpJ vrb/T3dT9g3+AvSVDpZmgYgi9smWOj0usVVkZkywDVF4L25hadZFa83c3ikaKqEs+gEZ YXFadle70LwS57gj1lAzLW3tgQlWlRmEjTB5j1hqPiBlD9CugPBE5dGKbu5WrCMwIcYa BGWjCeDeZ/HUQTFsOfdw9iPtF+emEZXMHgn9MaV6mHstgW+2FBL0got7ByBD0eOjGepx l3DQ== X-Gm-Message-State: AOPr4FWmJgWxHNn2ISPTV7bK/zkUDuF19F6gWnWAoa4cxnQAdlhsNVDpfHDEOVg+TpPyRA== X-Received: by 10.66.249.166 with SMTP id yv6mr4918214pac.91.1461080783339; Tue, 19 Apr 2016 08:46:23 -0700 (PDT) Received: from bubble.grove.modra.org (CPE-58-160-146-233.sa.bigpond.net.au. [58.160.146.233]) by smtp.gmail.com with ESMTPSA id i1sm91827032pfj.17.2016.04.19.08.46.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Apr 2016 08:46:22 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 5B176EA0153; Wed, 20 Apr 2016 01:16:18 +0930 (ACST) Date: Tue, 19 Apr 2016 15:46:00 -0000 From: Alan Modra To: Richard Biener Cc: "H.J. Lu" , 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: <20160419154618.GA20119@bubble.grove.modra.org> References: <56FB5061.9010303@redhat.com> <20160330143421.GM15812@bubble.grove.modra.org> <571161D0.10601@redhat.com> <20160418144911.GG15088@bubble.grove.modra.org> <20160419050805.GI15088@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.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00299.txt.bz2 On Tue, Apr 19, 2016 at 10:20:23AM +0200, Richard Biener wrote: > On Tue, Apr 19, 2016 at 7:08 AM, Alan Modra wrote: > > On Mon, Apr 18, 2016 at 07:59:50AM -0700, H.J. Lu wrote: > >> On Mon, Apr 18, 2016 at 7:49 AM, Alan Modra wrote: > >> > On Mon, Apr 18, 2016 at 11:01:48AM +0200, Richard Biener wrote: > >> >> To summarize: there is currently no testcase for a wrong-code issue > >> >> because there is no wrong-code issue. > > > > I've added a testcase at > > https://sourceware.org/bugzilla/show_bug.cgi?id=19965#c3 > > that shows the address problem (&x != x) with older gcc *or* older > > glibc, and shows the program behaviour problem with current > > binutils+gcc+glibc. > > Thanks. > > So with all this it sounds that current protected visibility is just broken > and we should forgo with it, making it equal to default visibility? Well, using protected visibility variables makes no sense in executables. They really are only useful in shared libraries, but have been of limited use on architectures like x86 for a long time due to non-PIC executable copying shared library variables into .dynbss. The concepts of copying variables into .dynbss, and protected visibility, are fundamentally incompatible. HJ's changes addressed the program level semantic issues, but in the process lost the main reason to use protected visibility variables, which is to tell a compiler that a global variable cannot be preempted (and therefore can use faster code for access, typically pc or GOT pointer relative rather than GOT indirect.) So IMO, "of limited use" has now become "not much use at all" on x86_64 and other architectures that have blindly followed suit. > At least I couldn't decipher a solution that solves all of the issues > with protected visibility apart from trying to error at link-time > (or runtime?) for the cases that are tricky (impossible?) to solve. I described the problem and solutions in https://sourceware.org/ml/binutils/2016-03/msg00431.html. A followup by Cary pointed out that one of the solutions, emitting text dynamic relocations, won't work on some architectures (of which x86_64 is one). > glibc uses "protected visibility" via its using of local aliases, correct? Yes, glibc defines a hidden visibility symbol for internal use, with an exported alias. > But it doesn't use anything like that for data symbols? I believe it does. See occurrences of libc_hidden_data_def. -- Alan Modra Australia Development Lab, IBM