From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 37852 invoked by alias); 15 May 2015 23:44: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 37842 invoked by uid 89); 15 May 2015 23:44:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RDNS_DYNAMIC,TVD_RCVD_IP autolearn=no version=3.3.2 X-HELO: brightrain.aerifal.cx Received: from 216-12-86-13.cv.mvl.ntelos.net (HELO brightrain.aerifal.cx) (216.12.86.13) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 15 May 2015 23:44:17 +0000 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1YtPGu-0002e8-00; Fri, 15 May 2015 23:44:04 +0000 Date: Fri, 15 May 2015 23:49:00 -0000 From: Rich Felker To: "H.J. Lu" Cc: Jan Hubicka , Alexander Monakov , GCC Patches , Uros Bizjak Subject: Re: [PATCH i386] Allow sibcalls in no-PLT PIC Message-ID: <20150515234403.GG17573@brightrain.aerifal.cx> References: <20150515194824.GB14415@kam.mff.cuni.cz> <20150515202319.GE17573@brightrain.aerifal.cx> <20150515204237.GF17573@brightrain.aerifal.cx> <20150515230810.GA73210@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2015-05/txt/msg01471.txt.bz2 On Fri, May 15, 2015 at 04:14:07PM -0700, H.J. Lu wrote: > On Fri, May 15, 2015 at 4:08 PM, Jan Hubicka wrote: > > Hello, > >> > >> There are codes like > >> > >> extern void foo (void); > >> > >> void > >> bar (void) > >> { > >> foo (); > >> } > >> > >> Even with LTO, compiler may have to assume foo is external > >> when foo is compiled with LTO. > > > > This is not exactly true if FOO is defined in other translation unit > > compiled with LTO and hidden visibility. > > I was meant to say " when foo is compiled without LTO.". > > > OK, so as I get it, we get the following cases: > > > > 1) compiler knows it is generating call to a local symbol a current > > unit (binds_to_current_def_p returns true). > > > > We handle this correctly by doing IP relative call. > > > > 2) compiler knows it is generating call to a local symbol in DSO > > (binds_local_p return true) > > Currently I think this is only the -fno-pic case or case of explicit > > hidden visibility and in this case we do IP relative call. > > > > We may want to propose plugin API update adding PREVAILING_DEF_EXP. > > So copiler would be able to default to this case for PREVAILING_DEF > > and we will also catch cases where the symbol is defined in current > > DSO as weak symbol, but the definition is not LTO. > > This would be also way to communicate -Bsymbolic[-functions] across > > the plugin API. > > > > 3) compiler knows there is going to be definition in the current DSO > > (by seeing a COMDAT function body or resolution info) that is interposable > > but because the function is inline or -fno-semantic-interposition happens, > > the semantics will not change. > > > > In this case it would be nice to arrange IP relative call to the > > hidden alias. This may require an extension both on compiler and linker > > side. > > > > I was thinking of doing so for comdats by adding hidden alias with > > fixed mangling, like __gnu_.hiddenalias, and referring it. > > But I think it is not safe as linker may throw away section that > > is produced by GCC and prevail section that is not leaving to an undefined > > symbol? > > > > I think this is rather common case in C++ (never made any stats) because > > uninlined comdats are quite common. > > > > 4) compiler has no clue but linker may know better > > > > Here we traditionally always produce a PLT call. In cases the call > > is known to be hot in the program it makes sense to trade lazy binding > > for performance and produce call via GOT reference (-fno-plt). > > I also see that H.J.'s branch helps us to actually avoid the GOT > > reference in cases the symbol ends up binding locally. How the lazy > > binding with relaxation works? > > If there is no GOT slot allocated for symbol foo, linker should resolve > foo@GOTPLT(%ebx) to to its PLT slot address + 6, which is the push > instruction, to support lazy binding. Otherwise, linker should resolve it > to its GOT slot address. Forget lazy binding. It's dead anyway because serious distros want PIE+relro+bindnow+... If people really want lazy binding, they can use options which support it, but I don't want to keep suffering the codegen cost of lazy binding despite never using it. There should be an option to generate optimal code equivalent to what you get with Alexander Monakov's patches for those of us who aren't trying to support this legacy feature that precludes good performance and precludes hardening. Rich