From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12664 invoked by alias); 14 May 2003 23:51:15 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 12550 invoked from network); 14 May 2003 23:51:13 -0000 Received: from unknown (HELO mta05bw.bigpond.com) (139.134.6.95) by sources.redhat.com with SMTP; 14 May 2003 23:51:13 -0000 Received: from bubble.local ([144.135.24.75]) by mta05bw.bigpond.com (Netscape Messaging Server 4.15 mta05bw Jul 16 2002 22:47:55) with SMTP id HEWI9800.9JQ for ; Thu, 15 May 2003 09:51:08 +1000 Received: from CPE-144-136-188-60.sa.bigpond.net.au ([144.136.188.60]) by bwmam03bpa.bigpond.com(MAM V3.3.2 26/24114); 15 May 2003 09:51:08 Received: (qmail 4605 invoked by uid 179); 14 May 2003 23:51:07 -0000 Date: Wed, 14 May 2003 23:51:00 -0000 From: Alan Modra To: Richard Henderson , "H. J. Lu" , gcc@gcc.gnu.org Subject: Re: PATCH: Optimize protected call for i386 Message-ID: <20030514235107.GG957@bubble.sa.bigpond.net.au> Mail-Followup-To: Richard Henderson , "H. J. Lu" , gcc@gcc.gnu.org References: <20030513015330.GR2166@bubble.sa.bigpond.net.au> <20030512185613.A14533@lucon.org> <20030513020400.GS2166@bubble.sa.bigpond.net.au> <20030512192302.A14731@lucon.org> <20030513135912.GA966@bubble.sa.bigpond.net.au> <20030513142716.A20059@lucon.org> <20030514085453.GA957@bubble.sa.bigpond.net.au> <20030514074940.A2376@lucon.org> <20030514230253.GD957@bubble.sa.bigpond.net.au> <20030514232439.GC9567@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030514232439.GC9567@redhat.com> User-Agent: Mutt/1.4i X-SW-Source: 2003-05/txt/msg01481.txt.bz2 On Wed, May 14, 2003 at 04:24:39PM -0700, Richard Henderson wrote: > On Thu, May 15, 2003 at 08:32:53AM +0930, Alan Modra wrote: > > I see. I think this is wrong. gcc needs to emit the normal PIC call, > > ie. "call foo@PLT" so the the linker can set up a plt entry if > > needed. > > I disagree. > > > A plt entry is needed for protected symbols so that function > > pointer comparisons work, since the x86 ABI uses the .plt entry for > > the value of a function symbol referenced by a dynamic object. > > Consider liba.so exporting a protected symbol foo. Will a function > > pointer, value foo, passed to libb.so compare equal to &foo in > > libb.so? What about a function pointer, value foo, passed from > > libb.so back to liba.so? > > None of which has anything to do with call instructions. Well, it may be that the linker will set up a plt entry anyway, thus making the function pointer comparisons work properly. The problem is that if gcc emits "call foo" for protected syms, you'll get an R_386_PC32 reloc on foo. How is the linker supposed to distinguish this reloc from an R_386_PC32 on ".long foo - ."? In the second case, you really want to use the plt entry address. > If liba.so contains a call to foo, ld *knows* that foo *must* > resolve to the version in liba.so and nowhere else. Thus we > can direct the call to foo without going through a PLT entry. Exactly. ld can do this even when gcc emits "call foo@PLT". > If you take the address of foo, in *any* DSO, you will not be > using either R_386_PC32 or R_386_PLT32. You'll be using either > R_386_32 or R_386_GOT32. Does the ABI preclude use of R_386_PC32 from assembly? -- Alan Modra IBM OzLabs - Linux Technology Centre