From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3124 invoked by alias); 3 Feb 2015 22:03:24 -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 3114 invoked by uid 89); 3 Feb 2015 22:03:23 -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-oi0-f52.google.com Received: from mail-oi0-f52.google.com (HELO mail-oi0-f52.google.com) (209.85.218.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 03 Feb 2015 22:03:16 +0000 Received: by mail-oi0-f52.google.com with SMTP id h136so51461209oig.11 for ; Tue, 03 Feb 2015 14:03:15 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.134.200 with SMTP id pm8mr17251565oeb.61.1423000994964; Tue, 03 Feb 2015 14:03:14 -0800 (PST) Received: by 10.76.134.102 with HTTP; Tue, 3 Feb 2015 14:03:14 -0800 (PST) In-Reply-To: References: <20150203193615.GZ1746@tucnak.redhat.com> Date: Tue, 03 Feb 2015 22:03:00 -0000 Message-ID: Subject: Re: [PATCH x86_64] Optimize access to globals in "-fpie -pie" builds with copy relocations From: "H.J. Lu" To: Sriraman Tallam Cc: Jakub Jelinek , Uros Bizjak , "gcc-patches@gcc.gnu.org" , David Li , Cary Coutant Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00170.txt.bz2 On Tue, Feb 3, 2015 at 1:35 PM, Sriraman Tallam wrote: > On Tue, Feb 3, 2015 at 1:29 PM, H.J. Lu wrote: >> On Tue, Feb 3, 2015 at 1:20 PM, Sriraman Tallam wrote: >>> On Tue, Feb 3, 2015 at 11:36 AM, Jakub Jelinek wrote: >>>> On Tue, Feb 03, 2015 at 11:25:38AM -0800, Sriraman Tallam wrote: >>>>> This was the original patch to i386.c to let global accesses take >>>>> advantage of copy relocations and avoid the GOT. >>>>> >>>>> >>>>> @@ -13113,7 +13113,11 @@ legitimate_pic_address_disp_p (rtx disp) >>>>> return true; >>>>> } >>>>> else if (!SYMBOL_REF_FAR_ADDR_P (op0) >>>>> - && SYMBOL_REF_LOCAL_P (op0) >>>>> + && (SYMBOL_REF_LOCAL_P (op0) >>>>> + || (HAVE_LD_PIE_COPYRELOC >>>>> + && flag_pie >>>>> + && !SYMBOL_REF_WEAK (op0) >>>>> + && !SYMBOL_REF_FUNCTION_P (op0))) >>>>> && ix86_cmodel != CM_LARGE_PIC) >>>>> >>>>> I do not understand here why weak global data access must go through >>>>> the GOT and not use copy relocations. Ultimately, there is only going >>>>> to be one copy of the global either defined in the executable or the >>>>> shared object right? >>>>> >>>>> Can we remove the check for SYMBOL_REF_WEAK? >>>> >>>> So, what will then happen if the weak undef symbol isn't defined anywhere? >>>> In non-PIE binaries that is fine, the linker will store 0. >>>> But in PIE binaries, the 0 would be biased by the PIE load bias and thus >>>> wouldn't be NULL. >>> >>> Thanks for clarifying. >>> >>>> You can only optimize weak vars if there is some weak definition in the >>>> current TU. >>> >>> Would this be fine then? Replace !SYMBOL_REF_WEAK (op0) with >>> >>> !(SYMBOL_REF_WEAK (op0) && SYMBOL_REF_EXTERNAL_P (op0)) >>> >> >> The full condition is: >> >> && (SYMBOL_REF_LOCAL_P (op0) >> || (HAVE_LD_PIE_COPYRELOC >> && flag_pie >> && !SYMBOL_REF_WEAK (op0) >> && !SYMBOL_REF_FUNCTION_P (op0))) >> >> If the weak op0 is defined in the current TU, shouldn't >> SYMBOL_REF_LOCAL_P (op0) be true for PIE? > > Thats not what I see for this: > > zap.cc > --------- > __attribute__((weak)) > int glob; > > int main() > { > printf("%d\n", glob); > } > > (gdb) p debug_rtx(op0) > (symbol_ref/i:DI ("glob") ) > > (gdb) p SYMBOL_REF_LOCAL_P(op0) > $4 = false > > (gdb) p SYMBOL_REF_WEAK (op0) > $5 = 1 > > (gdb) p SYMBOL_REF_EXTERNAL_P (op0) > $6 = false > > Thanks So we aren't SYMBOL_REF_EXTERNAL_P nor SYMBOL_REF_LOCAL_P. What do we reference? -- H.J.