From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1542 invoked by alias); 4 Feb 2015 18:27:38 -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 1525 invoked by uid 89); 4 Feb 2015 18:27:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_50,KAM_STOCKGEN,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mail-vc0-f177.google.com Received: from mail-vc0-f177.google.com (HELO mail-vc0-f177.google.com) (209.85.220.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 04 Feb 2015 18:27:36 +0000 Received: by mail-vc0-f177.google.com with SMTP id hy4so1098855vcb.8 for ; Wed, 04 Feb 2015 10:27:34 -0800 (PST) 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:content-type; bh=cNYAz9+5sxQLxlr3Pdm/xFQDmVqDXgTV3GRcY6wEejk=; b=dDULGuuwqklkBbqSVCCc77mLvmFQjIMAYBH/tNetAD8OG3Mem+Oc3GE9lqAP4tFZsO xRAdOymoet/bPNZgWmGjpF+RIKABRNwqRjDALrE3c60Q0155uOTvAB+aUZse/qz1rKP7 nSk1RK0cKHvrdTTZilK/ye0bbB7Y+h89hD28LJSeilIXuieskPUZOws5Io4641fZjOVC O8PYvqIKxgIj3fXEzoij/1pyW2jnScVUxAmocbDDQQt7jAUWi0C4ZxCadv5JvWLcGfA7 mn1UIuVJbTqAXl9Vsc4JuuC56+TEYAQMEPtySnZWJJ7Gj3G3rsBTJVRC7Anrqosb2c+1 SRBQ== X-Gm-Message-State: ALoCoQn4fR4tJ2hpUd9WkxVVQtpzOgj9j5Of5+w459Y1KoDMrrWVWe8ZqY0fN02EhTtZC5vMpSHZ MIME-Version: 1.0 X-Received: by 10.52.128.71 with SMTP id nm7mr16866156vdb.83.1423074454457; Wed, 04 Feb 2015 10:27:34 -0800 (PST) Received: by 10.52.37.114 with HTTP; Wed, 4 Feb 2015 10:27:34 -0800 (PST) In-Reply-To: References: <20150203193615.GZ1746@tucnak.redhat.com> <20150203221935.GA1746@tucnak.redhat.com> Date: Wed, 04 Feb 2015 18:27:00 -0000 Message-ID: Subject: Re: [PATCH x86_64] Optimize access to globals in "-fpie -pie" builds with copy relocations From: Sriraman Tallam To: "H.J. Lu" 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/msg00270.txt.bz2 On Tue, Feb 3, 2015 at 5:16 PM, H.J. Lu wrote: > On Tue, Feb 3, 2015 at 2:19 PM, Jakub Jelinek wrote: >> On Tue, Feb 03, 2015 at 02:03:14PM -0800, H.J. Lu wrote: >>> So we aren't SYMBOL_REF_EXTERNAL_P nor >>> SYMBOL_REF_LOCAL_P. What do we reference? >> >> That is reasonable. There is no guarantee the extern weak symbol is local, >> it could very well be non-local. All that you know about the symbols is >> that its address is non-NULL in that case. >> > > This may be true for shared library. But it isn't true for PIE: Also, gcc and g++ are inconsistent about something even more simple: $ cat x.c int a; int main() { printf("%d\n", a); } With gcc -fPIE x.c SYMBOL_REF_LOCAL_P(op0) = false With g++ -fPIE x.c SYMBOL_REF_LOCAL_P(op0) = true Sri > > [hjl@gnu-6 copyreloc-3]$ cat x.c > __attribute__((weak)) > int a; > > extern void bar (void); > > int main() > { > if (a != 0) > __builtin_abort(); > bar (); > if (a != 30) > __builtin_abort(); > return 0; > } > [hjl@gnu-6 copyreloc-3]$ cat bar.c > int a = -1; > > void > bar () > { > a = 30; > } > [hjl@gnu-6 copyreloc-3]$ make > gcc -pie -O3 -g -fuse-ld=gold -fpie -c x.i > gcc -pie -O3 -g -fuse-ld=gold -fpic -c -o bar.o bar.c > gcc -pie -shared -o libbar.so bar.o > gcc -pie -O3 -g -fuse-ld=gold -o x x.o libbar.so -Wl,-R,. > ./x > [hjl@gnu-6 copyreloc-3]$ > > Even if a common symbol, a, is weak, all references to > a within PIE is local. > > -- > H.J.