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)


I am on i686-pc-linux-gnu. I'm seeing some odd results in my testcase which have me a little confused, maybe someone can explain what's going on. I have this class:

class A
{
  virtual void Foo();
};


and the definition of A::Foo() in a DSO.


If you unpack the attached testcase and build it, you'll get executables called test1 and test2. In test1, the vtable slot for A::Foo points directly to A::Foo, not to a PLT stub. In test2, it points to a PLT stub. The only difference is that in test2.cpp, I have an (unused) function which calls A::Foo() directly, rather than through the vtable. This is with gcc 3.3.2, binutils version is 2.13.90.0.18-9 (rpm).


Ian Lance Taylor wrote:
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.


-- -Brian Ryner bryner@brianryner.com

Attachment: virtual-test.tar.gz
Description: application/gzip


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