LLVM如何判断成员函数指针指向虚函数？及如何获取函数地址

Great question—member function pointers under the Itanium ABI (the standard LLVM uses for most Unix-like systems) are notoriously tricky because their layout and behavior shift drastically depending on whether they point to a regular member, virtual member, or even a member of a virtual base class. Let’s break down your questions one by one:

How to Distinguish Between Virtual and Non-Virtual Member Function Pointers #

First, let’s recap the core layout rules from the Itanium ABI:

• Non-virtual member function pointers: These are simple structs (in most cases) with two fields:
  1. A direct pointer to the function’s machine code address.
  2. A ptrdiff_t adjustor value (used to fix the this pointer in scenarios like multiple inheritance).
• Virtual member function pointers: Instead of storing a direct function address, these hold an offset into the class’s virtual table (vtable). The first field is the byte offset from the object’s vptr to the relevant entry in the vtable; the second field remains the this adjustor.

LLVM (via its Clang frontend) knows this distinction at compile time—when you take the address of a virtual function, Clang generates IR that represents the vtable offset, not a direct function pointer. At runtime, you can spot the difference by checking the layout: if the first field of the pointer is a small integer (usually a multiple of sizeof(void*), since vtable entries are pointers), it’s almost certainly a virtual member function pointer.

How to Get the Actual Function Address #

The approach depends entirely on whether the pointer points to a virtual or non-virtual function:

For Non-Virtual Member Functions #

You can cast the member function pointer to a custom struct matching the ABI layout to extract the direct address:

#include <cstddef>

// Matches Itanium ABI layout for non-virtual member pointers
struct NonVirtualMemPtr {
    void (*func_addr)();
    ptrdiff_t this_adjustor;
};

// Example usage
class MyClass {
public:
    void regular_func() {}
};

int main() {
    void (MyClass::*mem_ptr)() = &MyClass::regular_func;
    auto* cast_ptr = reinterpret_cast<NonVirtualMemPtr*>(&mem_ptr);
    void (*raw_func)() = cast_ptr->func_addr;
    // raw_func now holds the direct machine code address
    return 0;
}

Note: The adjustor matters if you plan to call the function—you’ll need to adjust the this pointer by that value before invoking the raw function.

For Virtual Member Functions #

The actual function address lives in the object’s vtable, so you need an instance of the class to resolve it at runtime:

#include <cstddef>

// Matches Itanium ABI layout for virtual member pointers
struct VirtualMemPtr {
    ptrdiff_t vtable_offset;
    ptrdiff_t this_adjustor;
};

class MyClass {
public:
    virtual void virtual_func() {}
};

int main() {
    void (MyClass::*mem_ptr)() = &MyClass::virtual_func;
    MyClass obj;
    
    auto* cast_ptr = reinterpret_cast<VirtualMemPtr*>(&mem_ptr);
    // Get the vtable pointer from the object
    void** vtable = *reinterpret_cast<void***>(&obj);
    // Calculate the index in the vtable (offset divided by pointer size)
    size_t vtable_index = cast_ptr->vtable_offset / sizeof(void*);
    void (*raw_func)() = reinterpret_cast<void(*)()>(vtable[vtable_index]);
    // raw_func now holds the resolved virtual function address
    return 0;
}

Again, don’t overlook the adjustor—when calling the raw function, you’ll need to adjust the this pointer by cast_ptr->this_adjustor.

How LLVM Determines if a Member Function Pointer Points to a Virtual Function #

LLVM handles this at two key stages:

1. Compile time: Clang tracks whether a function is virtual from its declaration. When you take the address of a virtual function, Clang generates an IR constant representing the vtable offset instead of a direct function reference. LLVM’s optimizers use this metadata to optimize calls (e.g., devirtualize if the object type is known at compile time).
2. Runtime: The code LLVM generates relies on the pointer’s layout. For virtual function pointers, it emits code to load the vtable entry using the stored offset; for non-virtual pointers, it jumps directly to the stored address. There’s no dedicated runtime "check" function—LLVM just generates the correct code path based on the pointer’s type known at compile time.

Important caveat: All of this is specific to the Itanium ABI. MSVC uses a completely different layout for member function pointers, so this code won’t work on Windows systems.

内容的提问来源于stack exchange，提问作者JiaHao Xu