This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: Optimize protected call for i386


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]