Re: Using the PLT for vtables (or not)

[mec dot gnu at mindspring dot com (Michael Elizabeth Chastain)]

Brian Ryner 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.

Actually, you would get the address of the PLT stub.  Try it.

  #include <stdio.h>
  int main ()
  {
    printf ("%p\n", &printf);
    return 0;
  }

This prints a PLT stub address when I run it on native i686-pc-linux-gnu
with a normal shared glibc.

As far as gcc is concerned, it just puts out "address of printf".
vtables are just the same thing.  (Try compiling with and without -fpic
and see if there is any difference in the generated assembly code
for your vtables).

It's the linker's job to decide whether "address of printf" resolves to
a PLT stub or to an actual symbol.  Up until about a week ago, it always
resolved to a stub.  Now the linker has an optimization where it can
resolve "address of ..." directly to the symbol and bypass the PLT in
some cases, which is the optimization that you are asking for.

The trouble with this optimization is that it confuses gdb.

Also, this optimization is not suitable in all cases because if someone
takes "&foo" as a data value (as opposed to just "call foo"), and then
compares that data value against "&foo" from somewhere else, they need
to get the same value all the time.  The only way to do that is to make
"&foo" be the address of the PLT stub all the time.

I don't know if references from a vtable is one of those cases that can
bypass the PLT.  And even if it can, it might be a bad idea.  It would
be hell to load a shared library and resolve 1000's of vtable references
at shlib load time -- that might slow down program initialization.
Better to spread it out with a 1-instruction hit on each method call.

(I bet this has been discussed in the past on the binutils list but
I am just learning about binutils).

Michael C