In this episode, we will see how invoking a virtual function in C++ translates into assembly instructions. We will see how our class instance is constructed and how it relates to the vtable. Then, we will see how this vtable is used to call the appropriate function.

If you have actually built the project and analyzed the binary in the previous episode, don’t forget to remove the -fno-rtti option and to rebuild the project. I will use this binary as a reference here.

In this episode, we will explore what vtables mean in terms of bytes within ELF files.

Build Output

On Linux, GCC produces ELF files as the result of the compilation process. In our project, the file is a.out, and we can use the file command to get details about it:

$ file a.out 
a.out: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=a87e1cb2356338a14f1a9aa2fef85fb7036bee65, for GNU/Linux 3.2.0, not stripped

If the compiler has generated vtables for Base and Derived, there must be corresponding symbols and bytes in the binary.

If you’ve been around C++ for a while, you’ve likely come across the terms “vtable”, “virtual table” or “virtual method table”. Vtables are not part of the C++ standard, even though this concept pops up almost immediately when you try to understand how virtual functions actually work in C++. Indeed, vtables are the most common implementation of polymorphism in C++.

You may also have already encountered a cryptic compilation error like “undefined reference to vtable for MyClass”. This may have left you perplexed because you didn’t explicitly create anything named “vtable” in your code. This error signals that, under the hood, the compiler generates vtables to handle virtual functions. If you’re curious about this error, here is a good discussion on Stack Overflow (the second answer is particularly enlightening).