From patchwork Wed Feb 4 23:10:26 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "H.J. Lu" X-Patchwork-Id: 436510 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 0007B140218 for ; Thu, 5 Feb 2015 10:11:05 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; q=dns; s=default; b=sTPR0xzkBCE+NgGMys c6CJbgaxZYiMlAKhiSZRXiWI8H5eGKRu/qEsLnQestt4SvxvMCS8iIevX2ZgDz/h 4/KJArkVzGADi7oWbi1fukOdNrAJOTSKdbf08mazET55zitD3/Z1hCBgnp2RnayB ne/cNII6K7jdTUuVRFZq7XHak= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; s=default; bh=ugkwsauZBM9E/mFw7FFRXNas ytE=; b=n+90NNaFaOpdYr5WsJwgAZAbQVGPpZg1FRMUVvox3fQiVqrwrS9jF+6f zRRKC9cy80dHnUIUf7SY5hfNL1TmY/cQyN0xhOPY8qNbw+be8SxYjpO8FXkkePnK 3bin0EouMMA/eLGBvzFm5QvJSLcJSLfLsf2KV13B6ew2anS4xC0= Received: (qmail 26301 invoked by alias); 4 Feb 2015 23:10:30 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 26287 invoked by uid 89); 4 Feb 2015 23:10:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.2 required=5.0 tests=AWL, BAYES_50, FREEMAIL_FROM, KAM_STOCKGEN, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-ob0-f171.google.com Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com) (209.85.214.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 04 Feb 2015 23:10:28 +0000 Received: by mail-ob0-f171.google.com with SMTP id gq1so4221422obb.2 for ; Wed, 04 Feb 2015 15:10:26 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.156.196 with SMTP id wg4mr482090oeb.11.1423091426315; Wed, 04 Feb 2015 15:10:26 -0800 (PST) Received: by 10.76.134.102 with HTTP; Wed, 4 Feb 2015 15:10:26 -0800 (PST) In-Reply-To: <50365BC5-5D7C-423A-803B-F8F6F040C865@gmail.com> References: <20150203193615.GZ1746@tucnak.redhat.com> <20150203221935.GA1746@tucnak.redhat.com> <20150204183127.GU1746@tucnak.redhat.com> <20150204184205.GW1746@tucnak.redhat.com> <50365BC5-5D7C-423A-803B-F8F6F040C865@gmail.com> Date: Wed, 4 Feb 2015 15:10:26 -0800 Message-ID: Subject: Re: [PATCH x86_64] Optimize access to globals in "-fpie -pie" builds with copy relocations From: "H.J. Lu" To: Bernhard Reutner-Fischer Cc: Sriraman Tallam , Jakub Jelinek , Uros Bizjak , "gcc-patches@gcc.gnu.org" , David Li , Cary Coutant X-IsSubscribed: yes On Wed, Feb 4, 2015 at 2:47 PM, Bernhard Reutner-Fischer wrote: > On February 4, 2015 11:37:01 PM GMT+01:00, "H.J. Lu" wrote: >>On Wed, Feb 4, 2015 at 1:53 PM, Sriraman Tallam >>wrote: >>> On Wed, Feb 4, 2015 at 10:57 AM, H.J. Lu wrote: >>>> On Wed, Feb 4, 2015 at 10:51 AM, Sriraman Tallam >> wrote: >>>>> On Wed, Feb 4, 2015 at 10:45 AM, H.J. Lu >>wrote: >>>>>> On Wed, Feb 4, 2015 at 10:42 AM, Jakub Jelinek >>wrote: >>>>>>> On Wed, Feb 04, 2015 at 10:38:48AM -0800, H.J. Lu wrote: >>>>>>>> Common symbol should be resolved locally for PIE. >>>>>>> >>>>>>> binds_local_p yes, binds_to_current_def_p no. >>>>>>> >>>>>> >>>>>> Is SYMBOL_REF_LOCAL_P set to binds_local_p or >>>>>> binds_to_current_def_p? >>>>> >>>>> Looks like binds_local_p: >>>>> >>>>> varasm.c: >>>>> void >>>>> default_encode_section_info (tree decl, rtx rtl, int first >>ATTRIBUTE_UNUSED) >>>>> { >>>>> ... >>>>> if (targetm.binds_local_p (decl)) >>>>> flags |= SYMBOL_FLAG_LOCAL; >>>>> >>>> >>>> Why is SYMBOL_REF_LOCAL_P false? >>> >>> In varasm.c, default_binds_local_p_1 >>> >>> >>> /* Default visibility weak data can be overridden by a strong symbol >>> in another module and so are not local. */ >>> else if (DECL_WEAK (exp) >>> && !resolved_locally) >> ^^^^^^^^^^^^^^^^^^^ >>Why is resolved_locally false? It should be true for common >>symbol when compiling for PIE. >> >>> local_p = false; >>> >>> For weak definition, it is set to false here. > > Yea and i think this is still wrong and known as > http://gcc.gnu.org/PR32219 > Try this. diff --git a/gcc/varasm.c b/gcc/varasm.c index eb65b1f..c95eebd 100644 --- a/gcc/varasm.c +++ b/gcc/varasm.c @@ -6826,7 +6826,15 @@ default_binds_local_p_1 (const_tree exp, int shlib) && (TREE_STATIC (exp) || DECL_EXTERNAL (exp))) { varpool_node *vnode = varpool_node::get (exp); - if (vnode && (resolution_local_p (vnode->resolution) || vnode->in_other_partition)) + /* If not building shared library, common or initialized symbols + are also resolved locally, regardless they are weak or not. */ + if ((!shlib + && (DECL_COMMON (exp) + || (DECL_INITIAL (exp) != NULL + && (in_lto_p + || DECL_INITIAL (exp) != error_mark_node)))) + || (vnode && (resolution_local_p (vnode->resolution) + || vnode->in_other_partition))) resolved_locally = true; if (vnode && resolution_to_local_definition_p (vnode->resolution))