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: Using the PLT for vtables (or not)


Brian Ryner <bryner@brianryner.com> writes:

> Ian Lance Taylor wrote:
> > action, you're going to get the address of the PLT.  So if it is OK to
> > take that special action, then you might as well take it when you
> > initialize the vtable at program start-up time.
> >
> 
> What sort of vtable initialization happens at startup time?  The
> vtables currently reside in a read-only section of memory, don't they?

Yes, that's what I meant, although I expressed it in a confusing
manner.  The initialization consists of loading the executable file
into memory.

> > The real question is whether it is OK to skip the PLT for vtable
> > entries.  Normally it is desirable to use the PLT because it permits
> > the main program to override calls made from within a shared library.
> > A vtable may be an exception to this, but that is not immediately
> > obvious to me.
> >
> 
> Well, consider that if I were to build up a struct or array of
> function pointers from a class's constructor, I would be getting the
> real function address, not a PLT stub.  This seems like the same thing
> conceptually as a vtable, and yet it would not have the PLT overhead.

Hmmm, I think I made an incorrect assumption here.  What target are
you talking about?  The behaviour I see for a vtable on
i686-pc-linux-gnu is the same as building an array of function
pointers by hand.  What actually happens depends upon whether you use
-fpic when compiling and whether you link the vtable into a shared
library.

What target are you using?  Can you give a complete example of what
you are talking about?

Ian


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