From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50262 invoked by alias); 1 May 2015 03:26:18 -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 50172 invoked by uid 89); 1 May 2015 03:26:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-vn0-f54.google.com Received: from mail-vn0-f54.google.com (HELO mail-vn0-f54.google.com) (209.85.216.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 01 May 2015 03:26:03 +0000 Received: by vnbg129 with SMTP id g129so9431158vnb.4 for ; Thu, 30 Apr 2015 20:26:00 -0700 (PDT) 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:content-type; bh=RnaRmFWtKezdYaeQQhCj1HRzReaD3TnbnRzrl7A0zc0=; b=iHvqPV3voZju+dhpaG4I07M6QDO1ITIr+YXJPRFi6EQHDYi2uuQs5csBzeez0onKyl MjegVw9UlDT0C3rtULshC+2gKe5WpsKux3sq/xmkaFp9wmp/PptcDcVo8mzrT3RHpkzF UKF+Fa3/MORguwitou+YWScsRSswpIQ9RkJxToBw7m7UB1RvX3o/nRouBmLkOu3LNlL6 lk7qYbL9L3Rv97yUEML0+peiF2yJnHXNwythBNRgTeb8ZeZBY9nsUdrjgJIjbaCcjh3q nnSB2k4GOrYdrPnxkzrLFtO2vyeoWQrQdR8MTGTuYQ1rZssg3ZgV/UVb/Mnfx+tsZ9eg hKJA== X-Gm-Message-State: ALoCoQk2yYruftRrFL2moezpnw1BcPnzKLnttpmJbgxuLoO/fCFnnqjKsRr4YzDWipnkDSB6947D MIME-Version: 1.0 X-Received: by 10.52.126.235 with SMTP id nb11mr12129161vdb.58.1430450760434; Thu, 30 Apr 2015 20:26:00 -0700 (PDT) Received: by 10.52.121.18 with HTTP; Thu, 30 Apr 2015 20:26:00 -0700 (PDT) In-Reply-To: <20150501032132.GA4302@bubble.grove.modra.org> References: <20150501032132.GA4302@bubble.grove.modra.org> Date: Fri, 01 May 2015 03:26:00 -0000 Message-ID: Subject: Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt= From: Sriraman Tallam To: Sriraman Tallam , GCC Patches , "H.J. Lu" , David Li Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00003.txt.bz2 On Thu, Apr 30, 2015 at 8:21 PM, Alan Modra wrote: > 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. With -fno-plt= option, you are choosing functions that are hot and PLT must be avoided. Losing lazy binding on these should be perfectly fine because they would be called. Thanks Sri 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