Function pointer from pointer-to-members

Question

This has come up before, but the questions are slightly different, and the answers were all quite unhelpful, so I'll try one more time.

I need 2 pieces information from the compiler which seem to be difficult to extract.

1. I want to find the vtable pointer for a given class without an instance of the class. The only reference I can find to the vtable symbol anywhere in the binary is in the constructor where it's assigned to new instances, and it's really awkward to get the pointer out of the constructor without calling it... I'm wondering if anyone can point to the vtable name mangling spec for common compilers (msvc, gcc, clang) so I can extern to the symbol explicitly? (I haven't been able to find this). My concern with this is that I suspect (at least on VC) that the symbol name has some characters that are illegal in C++ identifiers, so I'm not sure how to create a variable that links to it...

2. I need the actual function pointers for methods. The only syntax that seems to be available to approach member function pointers is the pointer-to-member operator, and that results in very compiler-specific output.

   I have observed, GCC/Clang produce a nice little struct; { void *ptr_or_offset; size_t suspected_vtable; }. From that, it's easy enough to find the actual function pointer (assuming I have the vtable pointer! see #1).

   MSVC is a little harder; pointer-to-members for virtuals are pointers to thunk functions that perform the virtual lookup. It seems the thunk's correlate with the vtable offset, so there is one thunk for each vtable offset. This strategy makes it very hard to; identify if the method is virtual or not, and if it is, get the vtable offset (and therefore the actual function pointer). I'm thinking maybe I can fabricate a table of thunk pointers for each vtable offset up to some N, then when I take a pointer-to-member, I can compare it with each item in the thunk table; if it is among them, I know it is virtual, and the vtable offset, so I can get the pointer.

So, this all sounds horrible, but it is what it is since C++ doesn't feel like syntax should be available to get these fundamental language primitives, and doesn't have proper delegates for some unknown reason!

Can anyone think of a better or more-direct mechanism to capture those pieces of data that I seek? Or any alternative solutions which would improve on portability would also be cool!

Cheers!

Edit: Considering there are other posts similar to this already filled with people saying that 'it's not portable', and 'don't do it', I'd like to request that you refrain from polluting this thread with more of the same. They are worthless comments that don't address the problem. This problem requires some creative thinking, impress us with the quality of your solution.

Edit 2: Not sure why I'm being down-voted. This is an interesting and largely unsolved problem. There is very little topical discussion on the internets.

Answer 1

Virtual tables are not at all part of the c++ standard at all. Not a word about it in the whole ISO standard. It's only a commonly used implementation practice. This is why you'll find not tool support to do what you want.

Furthermore, virtual tables can be a very complex matter, for example in case of multiple inheritance, where several different virtual tables are used in the same object (for the different subobject).

You have found an astute way of get some info out, and have apparently already studied this in detail. However, I'm not sure that your way of finding out the vtable offset will work in all the different conditions. I'd strongly advise you to think over your problem and fin another way to implement it (unless you're working on new debugging tools and have no choice ;-) )

Answer 2

This is just a hint, and unsure whether it is relevant for you actual problem.

If you need to get access the the underlying vTables (which are only implementation details), you should think about explicit vTable management. That mean that all your dynamic classes should have no virtual functions, but only a pointer to an explicit vtable containing pointers to functions (not member functions) whose first parameter should be a pointer (or ref) to an object of the class.

You should then explicitely use a invoke function or macro that would at a moment calls something like : inner_invocation(object, offset_of_method, other_args...). Once you are there it becomes possible to call by hand the actual virtual member function.

Ok, it really looks like C++ in C but at least it allows to master the operation without relying too much on compilers implementation details.

---

After reading again your question, and your comments, here is a simple way to do dynamic derivation. That's what Java programmers call proxying: a proxy (Java sense) is a thin object that implements an interface (class containing only pure virtual methods) over a real object. Ok, Java provides all the machinery to create proxy and C++ is not so kind but is extensible enough to provide ways do build somethink like it.

You should simply forget about vtables and see them as interfaces - BTW you gain portability.

Here is an example showing how to implement two interfaces on a class:

#include <iostream>
#include <string>
#include <sstream>

// definition of template class proxy
template<class C, class ... I>
class Proxy: public C, public I... {
private:
    Proxy() {};
public:
    Proxy(const C& c): C(c) {};   // uses copy constructor on original object
    virtual ~Proxy() {};
};

/* if the proxy is not required to inherit from C, you can take a ref    
template<class C, class ... I>
class Proxy: public C, public I... {
private:
    C& obj;
    Proxy() {};
public:
    Proxy(const C& c): obj(c) {};   // just copy the reference
    virtual ~Proxy() {};
};
*/
// macro definition to help in proxy declarations
#define BEGIN_DECLARE_PROXY(proxy, cls, ...) \
class proxy: public Proxy<cls, __VA_ARGS__> { \
public: \
    proxy(const C& c): Proxy(c) {}; \

#define IMPLEMENT0(type, method, function) \
    type method() { \
        return function(*this ); \
    }
#define IMPLEMENT1(type, method, function, typ1, arg1) \
    type method(typ1 arg1) { \
        return function(*this, arg1 ); \
    }
#define IMPLEMENT2(type, method, function, typ1, arg1, typ2, arg2) \
    type method(typ1 arg1, typ2 arg2) { \
        return function(*this, arg1, arg2); \
    }
#define IMPLEMENT3(type, method, function, typ1, arg1, typ2, arg2, typ3, arg3) \
    type method(typ1 arg1, typ2 arg2, typ3, arg3) { \
        return function(*this, arg1, arg2, arg3); \
    }
// could add many others - could not use VA_ARGS here ...
/* if we used the ref. version, implementation should be return function(obj, ...); */

#define END_DECLARE_PROXY };

// example actual class
struct C {
    int val;
    std::string name;
};

// example interfaces
class I {
public:
    virtual std::string display() = 0;
};

class I2 {
public:
    virtual void show(std::ostream& out) = 0;
};

// function implementing the interfaces
std::string C_display(const C& c) {
    std::stringstream ss;
    ss << c.name << " (" << c.val << ")";
    return ss.str();
}

void C_show(const C& c, std::ostream& out) {
    out << C_display(c) << std::endl;
}

// actual proxy definition
BEGIN_DECLARE_PROXY(CI, C, I, I2)
IMPLEMENT0(std::string, display, C_display)
IMPLEMENT1(void, show, C_show, std::ostream&, out)
END_DECLARE_PROXY

int main() {
    C c = {12, "Foo"}; // create an object
    CI ci(c);   // build a proxy around the object
    I& i = ci;  // an interface on the proxy

    // example calls
    std::cout << i.display() << std::endl;
    ci.show(std::cout);

    return 0;
}

Answer 3

I've been working on this, and I've worked it into a lib: https://github.com/TurkeyMan/virtualwrangler

It's 99% done, I just need a GCC implementation for:

template <typename C>
inline VTable GetVTable();

Can anyone think of any creative ways to coerce GCC into producing the vtable ptr for some class? The best I have is:

extern "C" void *_ZTV7MyClass;

Which would be fine, except the symbol name has the number '7' in there, which is the string length of the name of the class!! Which means I can't work that declaration into a macro... unless there's some clever way to perform a preprocessor stringlen...?

Ideas?