[llvm-dev] Question: How to access c++ vtable pointer to use as Value* in LLVM pass

Tim Northover via llvm-dev llvm-dev at lists.llvm.org
Thu Apr 18 23:06:43 PDT 2019


On Fri, 19 Apr 2019 at 05:13, K Jelesnianski via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> But this doesn't give me a Value* handle i can grab to and use later.
> How can I leverage this Value to get that contained ??

You need to get that from an instance rather than by iterating over
the Type; almost certainly from a pointer to an instance since classes
are hardly ever loaded as a whole in LLVM, just individual fields when
needed. It sounds like you'll have one lying around.

After that, you'd write:

    %vtable.ptr = getelementptr %MyStruct, %MyStruct* %obj, i32 0, i32 0
    %vtable = load i32(...)*, i32(...)** %vtable.ptr

The first index on that GEP is just because your object may be in an
array, the second selects the vtable pointer. Loading it gives you a
*pointer* to the vtable (so the object instance is a pointer to a
pointer to the vtable). It's essentially what you'd get if you'd had a
Value * from Clang's @_ZTV8MyStruct directly (via
Module::getGlobalVariable).

You have to bitcast it to the correct type, of course, because at the
moment it's pretending to be a i32(...)*. But that's probably what you
want to pass to your library function if it's expecting a vtable.

> 2nd question: What happens if the struct object is from a derived
> class; iterating over the struct again, it looks like the vtable ptr
> is tangled even deeper within the object:

It can get horribly complicated, with multiple vtables inside the
object at different locations and vtables within vtables; sometimes
even different vtables at different stages of the object's life. The
specification of what goes where is here:
https://itanium-cxx-abi.github.io/cxx-abi/abi.html

This is a good time to point out that all of this is platform
dependent. MSVC in particular does things very differently, and Clang
on Windows follows it.

Cheers.

Tim.


More information about the llvm-dev mailing list