From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83708 invoked by alias); 11 May 2015 14:20:06 -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 83687 invoked by uid 89); 11 May 2015 14:20:05 -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; Mon, 11 May 2015 14:20:00 +0000 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1YroYV-00028d-00; Mon, 11 May 2015 14:19:39 +0000 Date: Mon, 11 May 2015 14:20:00 -0000 From: Rich Felker To: Michael Matz Cc: "H.J. Lu" , Alexander Monakov , Jakub Jelinek , Jeff Law , GCC Patches Subject: Re: [PATCH] Expand PIC calls without PLT with -fno-plt Message-ID: <20150511141939.GS17573@brightrain.aerifal.cx> References: <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> 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/msg00939.txt.bz2 On Mon, May 11, 2015 at 01:48:03PM +0200, Michael Matz wrote: > Hi, > > On Wed, 6 May 2015, Rich Felker wrote: > > > I don't see how this case is improved unless GCC is failing to consider > > strong definitions in the same TU as locally-binding. > > Interposition of non-static non-inline non-weak symbols is supported > independend of if they are defined in the same TU or not (if you're > producing a shared lib, that is). I.e. no, they are not considered > locally-binding (for instance, they aren't automatically inlined). > > > If this is the case, is there a reason for that behavior? > > Because IMHO interposition is orthogonal to TU placement, and hence > shouldn't be influenced by it. There's visibility, inline hints or > static-ness to achieve different effects. (perhaps the real reason is: > because it always worked like that :) ) > > > IMO it's wrong. > > Why? I think it's right. I see it as an unnecessary pessimization. The ELF shared library semantics for allowing interposition were designed to avoid behavioral regressions versus static linking, and this is not such a case. With an archive-type library, it's possible to cause whole TUs to be omitted when linking as long as whatever symbol(s) may have been needed from them are already defined elsewhere; interposition makes the same possible with dynamic linking. But if symbols A and B were both in the same TU, having A defined prior to searching an archive but B undefined will cause the TU that defines both to be pulled in, and is such a linking error (multiple definitions). So I'm not sure why it's desirable to support this. The "it always worked like that" argument may suffice if people are depending on this behavior now (OTOH I'd rather see it break so they fix their breakage of static linking) but I suspect the historical reason it worked like that is that compilers were not smart enough to process whole TUs at a time but just worked with one function at a time and did not know that a referenced symbol was in the same TU. BTW visibility can't really address the issue except with hacks (hidden aliases) or protected visibility (which is hard to use because it's broken on lots of toolchain versions). Rich