From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46901 invoked by alias); 6 Mar 2015 04:19:40 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 46875 invoked by uid 89); 6 Mar 2015 04:19:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_FROM_URIBL_PCCC,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-pd0-f170.google.com Received: from mail-pd0-f170.google.com (HELO mail-pd0-f170.google.com) (209.85.192.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 06 Mar 2015 04:19:39 +0000 Received: by pdbfl12 with SMTP id fl12so40739412pdb.9 for ; Thu, 05 Mar 2015 20:19:37 -0800 (PST) X-Received: by 10.68.100.99 with SMTP id ex3mr21677801pbb.7.1425615577308; Thu, 05 Mar 2015 20:19:37 -0800 (PST) Received: from bubble.grove.modra.org (CPE-58-160-155-134.oycza5.sa.bigpond.net.au. [58.160.155.134]) by mx.google.com with ESMTPSA id oy3sm8325098pdb.56.2015.03.05.20.19.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Mar 2015 20:19:36 -0800 (PST) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 92139EA0150; Fri, 6 Mar 2015 14:49:31 +1030 (ACDT) Date: Fri, 06 Mar 2015 04:19:00 -0000 From: Alan Modra To: "H.J. Lu" Cc: GCC Patches , GNU C Library , Binutils Subject: Re: RFC: PATCHES: Properly handle reference to protected data on x86 Message-ID: <20150306041931.GE25172@bubble.grove.modra.org> Mail-Followup-To: "H.J. Lu" , GCC Patches , GNU C Library , Binutils References: 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: 2015-03/txt/msg00328.txt.bz2 On Wed, Mar 04, 2015 at 03:26:10PM -0800, H.J. Lu wrote: > Protected symbol means that it can't be pre-emptied. It > doesn't mean its address won't be external. This is true > for pointer to protected function. With copy relocation, > address of protected data defined in the shared library may > also be external. We only know that for sure at run-time. > Here are patches for glibc, binutils and GCC to handle it > properly. > > Any comments? I'd like to see this pass some more tests. For example reference in non-PIC exe to var x protected visibility definition of x in libA protected visibility definition of x in libB I suspect you don't have this case correct, but congratulations if you do! Assuming libA is first on the breadth first search for libraries, then exe and libA ought to use the same x, but libB have its own x. In fact it would be good to prove that all variations of either a reference, a default visibility definition or a protected visibility definition worked in the exe plus two libs case. -- Alan Modra Australia Development Lab, IBM