From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130337 invoked by alias); 6 May 2015 19:24:19 -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 130327 invoked by uid 89); 6 May 2015 19:24:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f173.google.com Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com) (209.85.214.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 06 May 2015 19:24:17 +0000 Received: by obblk2 with SMTP id lk2so15015934obb.0 for ; Wed, 06 May 2015 12:24:15 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.59.106 with SMTP id y10mr210802oeq.45.1430940255241; Wed, 06 May 2015 12:24:15 -0700 (PDT) Received: by 10.76.54.14 with HTTP; Wed, 6 May 2015 12:24:15 -0700 (PDT) In-Reply-To: <20150506191750.GM17573@brightrain.aerifal.cx> References: <5547AF7C.9030500@redhat.com> <20150506154554.GZ1751@tucnak.redhat.com> <20150506173521.GJ17573@brightrain.aerifal.cx> <20150506183735.GK17573@brightrain.aerifal.cx> <20150506190128.GL17573@brightrain.aerifal.cx> <20150506191750.GM17573@brightrain.aerifal.cx> Date: Wed, 06 May 2015 19:24:00 -0000 Message-ID: Subject: Re: [PATCH] Expand PIC calls without PLT with -fno-plt From: "H.J. Lu" To: Rich Felker Cc: Alexander Monakov , Jakub Jelinek , Jeff Law , GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00498.txt.bz2 On Wed, May 6, 2015 at 12:17 PM, Rich Felker wrote: > On Wed, May 06, 2015 at 12:05:20PM -0700, H.J. Lu wrote: >> >> -Bsymbolic will bind all references to local definitions in shared libraries, >> >> with and without visibility, weak or non-weak. Compiler can use it >> >> in binds_tls_local_p and we can generate much better codes in shared >> >> libraries. >> > >> > Yes, I'm aware of what it does. But at compile-time the compiler can't >> > know whether the referenced symbol will be defined in the same DSO >> > unless this is visibility annotation telling it. Even when linking a >> > shared library using -Bsymbolic, the library code can still make calls >> > (or data references) to symbols in other DSOs. >> >> Even without LTO, -fsymbolic -fPIC will generate better codes for >> >> --- >> int glob_a = 1; >> >> int foo () >> { >> return glob_a; >> } >> --- > > I see how this case is improved, but it depends on the dubious (and > undocumented?) behavior of -Bsymbolic breaking copy relocations. -Bsymbolic breaks copy relocations, independent of compiler. However, we can pass -fsymbolic when building PIE to avoid copy relocation. With -fsymbolic -fPIE -pie -flto, we can generate direct reference for locally defined symbol. >> and >> >> --- >> int glob_a (void) >> { >> return -1; >> } >> >> int foo () >> { >> return glob_a (); >> } >> --- > > I don't see how this case is improved unless GCC is failing to > consider strong definitions in the same TU as locally-binding. If this > is the case, is there a reason for that behavior? IMO it's wrong. glob_a is a strong definition. If you have another strong definition, you will get a linker error. -- H.J.