From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39190 invoked by alias); 1 May 2015 03:21:43 -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 39179 invoked by uid 89); 1 May 2015 03:21:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f43.google.com Received: from mail-pa0-f43.google.com (HELO mail-pa0-f43.google.com) (209.85.220.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 01 May 2015 03:21:41 +0000 Received: by pacyx8 with SMTP id yx8so79109122pac.1 for ; Thu, 30 Apr 2015 20:21:39 -0700 (PDT) X-Received: by 10.70.90.162 with SMTP id bx2mr13946046pdb.60.1430450499600; Thu, 30 Apr 2015 20:21:39 -0700 (PDT) Received: from bubble.grove.modra.org (CPE-58-160-155-134.oycza5.sa.bigpond.net.au. [58.160.155.134]) by mx.google.com with ESMTPSA id f1sm3482799pds.62.2015.04.30.20.21.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Apr 2015 20:21:38 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 38AD0EA0072; Fri, 1 May 2015 12:51:33 +0930 (ACST) Date: Fri, 01 May 2015 03:21:00 -0000 From: Alan Modra To: Sriraman Tallam Cc: GCC Patches , "H.J. Lu" , David Li Subject: Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt= Message-ID: <20150501032132.GA4302@bubble.grove.modra.org> Mail-Followup-To: Sriraman Tallam , GCC Patches , "H.J. Lu" , David Li References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00002.txt.bz2 On Thu, Apr 30, 2015 at 05:31:30PM -0700, Sriraman Tallam wrote: > This comes with caveats. This cannot be generally done for all > functions marked extern as it is impossible for the compiler to say if > a function is "truly extern" (defined in a shared library). If a > function is not truly extern(ends up defined in the final executable), > then calling it indirectly is a performance penalty as it could have > been a direct call. Further, the newly created GOT entries are fixed > up at start-up and do not get lazily bound. I've considered something similar for PowerPC (but didn't consider doing do so for a subset of calls). Losing lazy symbol resolution is a real problem. The other problem you cite of indirect calls that could be direct can be fixed in the linker relatively easily. Edit this code 0: ff 15 00 00 00 00 callq *0x0(%rip) # 0x6 2: R_X86_64_GOTPCREL foo-0x4 6: ff 25 00 00 00 00 jmpq *0x0(%rip) # 0xc 8: R_X86_64_GOTPCREL foo-0x4 to this c: e8 00 00 00 00 callq 0x11 d: R_X86_64_PC32 foo-0x4 11: 90 nop 12: e9 00 00 00 00 jmpq 0x17 13: R_X86_64_PC32 foo-0x4 17: 90 nop You may need to have gcc or gas add a marker reloc to say exactly where an instruction starts. -- Alan Modra Australia Development Lab, IBM