From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9788 invoked by alias); 14 May 2003 23:50:10 -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 9758 invoked from network); 14 May 2003 23:50:10 -0000 Received: from unknown (HELO rwcrmhc51.attbi.com) (204.127.198.38) by sources.redhat.com with SMTP; 14 May 2003 23:50:10 -0000 Received: from lucon.org (12-234-88-5.client.attbi.com[12.234.88.5]) by attbi.com (rwcrmhc51) with ESMTP id <2003051423500905100329she>; Wed, 14 May 2003 23:50:09 +0000 Received: by lucon.org (Postfix, from userid 1000) id 28C312C681; Wed, 14 May 2003 16:50:07 -0700 (PDT) Date: Wed, 14 May 2003 23:50:00 -0000 From: "H. J. Lu" To: Richard Henderson , gcc@gcc.gnu.org Subject: Re: PATCH: Optimize protected call for i386 Message-ID: <20030514165007.A10337@lucon.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 User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030514232439.GC9567@redhat.com>; from rth@redhat.com on Wed, May 14, 2003 at 04:24:39PM -0700 X-SW-Source: 2003-05/txt/msg01480.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. Since "call foo" and ".long foo - ." will both generate a R_386_PC32 relocation against foo, linker can't resolve R_386_PC32 against a protected symbol without knowing how it is used. "call foo@PLT" solves this problem for linker. > > > 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. > > 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. > > 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. But the currrent gcc uses R_386_GOTOFF for address of a protected data or function symbol on x86 when PIC is used. I will say it is a bug. R_386_GOT32 should be used here. I can provide a testcase if asked. H.J.