From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4909 invoked by alias); 6 May 2015 15:46:03 -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 4899 invoked by uid 89); 6 May 2015 15:46:02 -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,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 06 May 2015 15:46:01 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t46Fk06W013308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 6 May 2015 11:46:00 -0400 Received: from tucnak.zalov.cz (ovpn-116-89.ams2.redhat.com [10.36.116.89]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t46Fjwgt005741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 6 May 2015 11:45:59 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id t46FjvW2018387; Wed, 6 May 2015 17:45:57 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id t46FjsIq018386; Wed, 6 May 2015 17:45:54 +0200 Date: Wed, 06 May 2015 15:46:00 -0000 From: Jakub Jelinek To: Alexander Monakov Cc: Jeff Law , gcc-patches@gcc.gnu.org, Rich Felker Subject: Re: [PATCH] Expand PIC calls without PLT with -fno-plt Message-ID: <20150506154554.GZ1751@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <1430757479-14241-1-git-send-email-amonakov@ispras.ru> <1430757479-14241-6-git-send-email-amonakov@ispras.ru> <5547AD8D.9080806@redhat.com> <20150504173955.GE1751@tucnak.redhat.com> <5547AF7C.9030500@redhat.com> 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/msg00474.txt.bz2 On Wed, May 06, 2015 at 06:24:58PM +0300, Alexander Monakov wrote: > If the same PLT stubs as today are to be used, it constrains the compiler on > 32-bit x86 and possibly other arches where PLT stubs need GOT pointer in a > specific register. It's possible to imagine more complex PLT stubs that > obtain GOT pointer on their own, but in that case you can't let optimizations > such as loop invariant motion move the GOT load away from the call in a > fashion that could result in PLT stub pointer be reused many times. Why? 32-bit x86 (shouldn't we care much more about x86-64, where this is a non-issue?) PLT looks like: 4c2b7310 <_Unwind_Find_FDE@plt-0x10>: 4c2b7310: ff b3 04 00 00 00 pushl 0x4(%ebx) 4c2b7316: ff a3 08 00 00 00 jmp *0x8(%ebx) 4c2b731c: 00 00 add %al,(%eax) ... 4c2b7320 <_Unwind_Find_FDE@plt>: 4c2b7320: ff a3 0c 00 00 00 jmp *0xc(%ebx) 4c2b7326: 68 00 00 00 00 push $0x0 4c2b732b: e9 e0 ff ff ff jmp 4c2b7310 4c2b7330 : 4c2b7330: ff a3 10 00 00 00 jmp *0x10(%ebx) 4c2b7336: 68 08 00 00 00 push $0x8 4c2b733b: e9 d0 ff ff ff jmp 4c2b7310 The linker would know very well what kind of relocations are used for particular PLT slot, and for the new relocations which would resolve to the address of the .got.plt slot it could just tweak corresponding 3rd insn in the slot, to not jump to first plt slot - 16, but a few bytes before that that would just load the address of _G_O_T_ into %ebx and then fallthru into the 0x4c2b7310 snippet above. The lazy binding would be a few ticks slower in that case, but no requirement on %ebx to contain _G_O_T_. As for hoisting the load of the call address before the loop, with lazy binding that has the obvious disadvantage that you'd resolve the slot again and again, if you are unlucky enough that the function hasn't been resolved yet. Unless the shared PLT stub after computing _G_O_T_ (for x86) also rechecks the .got.plt address. Jakub