This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: Optimize protected call for i386
- From: Richard Henderson <rth at redhat dot com>
- To: "H. J. Lu" <hjl at lucon dot org>, gcc at gcc dot gnu dot org
- Date: Wed, 14 May 2003 16:24:39 -0700
- Subject: Re: PATCH: Optimize protected call for i386
- References: <20030512184927.A14308@lucon.org> <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>
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.
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.
r~