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.

Inspect the Symbols

Let's identify the symbols related to these classes. We can use objdump to get the symbol table, employ sort to order the symbols by addresses, and filter the output to retain only what relates to Base and Derived:

$ objdump --syms --demangle a.out | sort | egrep "Base|Derived"
000000000000116a g     F .text  0000000000000015              Base::foo() const
0000000000001180 g     F .text  0000000000000015              Base::bar() const
0000000000001196 g     F .text  0000000000000015              Derived::foo() const
00000000000011ac g     F .text  0000000000000015              Derived::bar() const
00000000000011c1 g     F .text  000000000000000e              use(Base const&)
0000000000002042  w    O .rodata        0000000000000006              typeinfo name for Base
0000000000002048  w    O .rodata        0000000000000009              typeinfo name for Derived
0000000000003d68  w    O .data.rel.ro   0000000000000020              vtable for Base
0000000000003d88  w    O .data.rel.ro   0000000000000020              vtable for Derived
0000000000003da8  w    O .data.rel.ro   0000000000000010              typeinfo for Base
0000000000003db8  w    O .data.rel.ro   0000000000000018              typeinfo for Derived

If you are not familiar with the output format of objdump --syms, you can refer to the man pages of the command. The help of the --syms options provide with detailed information about each column.

We see the addresses of our 4 member functions, as well as use(). These functions are stored in the .text section, which is the dedicated section for code. We also see several objects (notice the O in the third column) for the information about the types and... the virtual tables! Let's dig into the contents of these tables.

Alternatives to objdump

Before we move to the hard values, I just want to briefly mention alternatives to objdump. Unfortunately, neither display the sections along with the symbols (please leave a comment if I have missed the magic options!).

Alternative 1 = nm

$ nm --demangle --print-size a.out | sort | egrep "Base|Derived"
000000000000116a 0000000000000015 T Base::foo() const
0000000000001180 0000000000000015 T Base::bar() const
0000000000001196 0000000000000015 T Derived::foo() const
00000000000011ac 0000000000000015 T Derived::bar() const
00000000000011c1 000000000000000e T use(Base const&)
0000000000002042 0000000000000006 V typeinfo name for Base
0000000000002048 0000000000000009 V typeinfo name for Derived
0000000000003d68 0000000000000020 V vtable for Base
0000000000003d88 0000000000000020 V vtable for Derived
0000000000003da8 0000000000000010 V typeinfo for Base
0000000000003db8 0000000000000018 V typeinfo for Derived

Alternative 2 : readelf

$ readelf --syms --demangle a.out | cut -d: -f2- | sort | egrep "Base|Derived"
 000000000000116a    21 FUNC    GLOBAL DEFAULT   15 Base::foo() const
 0000000000001180    21 FUNC    GLOBAL DEFAULT   15 Base::bar() const
 0000000000001196    21 FUNC    GLOBAL DEFAULT   15 Derived::foo() const
 00000000000011ac    21 FUNC    GLOBAL DEFAULT   15 Derived::bar() const
 00000000000011c1    14 FUNC    GLOBAL DEFAULT   15 use(Base const&)
 0000000000003d68    32 OBJECT  WEAK   DEFAULT   22 vtable for Base
 0000000000003d88    32 OBJECT  WEAK   DEFAULT   22 vtable for Derived
 0000000000003da8    16 OBJECT  WEAK   DEFAULT   22 typeinfo for Base
 0000000000003db8    24 OBJECT  WEAK   DEFAULT   22 typeinfo for Derived

To sort by addresses, we must remove the symbol number at the beginning of each line. Indeed, a line is formatted as follows:

22: 0000000000001180    21 FUNC    GLOBAL DEFAULT   15 Base::bar() const

Note that typeinfo name for Base and Derived are missing here (again, if you know why, leave a comment below!).

The Bytes in Vtables

Vtables and typeinfo symbols reside in the .data.rel.ro section. We need to examine the raw data of this section to understand their content. readelf can produce a hexdump of a section:

$ readelf --hex-dump .data.rel.ro a.out

Hex dump of section '.data.rel.ro':
  0x00003d68 00000000 00000000 a83d0000 00000000 .........=......
  0x00003d78 6a110000 00000000 80110000 00000000 j...............
  0x00003d88 00000000 00000000 b83d0000 00000000 .........=......
  0x00003d98 96110000 00000000 ac110000 00000000 ................
  0x00003da8 00000000 00000000 42200000 00000000 ........B ......
  0x00003db8 00000000 00000000 48200000 00000000 ........H ......
  0x00003dc8 a83d0000 00000000                   .=......

Note that:

• These are little-endian hexadecimal data. Hence, a83d0000 00000000 on the last line is in fact 0x0000000000003da8.
• The same dump can be created with objdump --section=.data.rel.ro --full-contents a.out.

Let's inspect these bytes.

How? By navigating through the symbol table to obtain the addresses and sizes of the symbols, and utilizing hexdumps to find out the bytes at these addresses. We will then gain a better understanding of these symbols.

Stay calm and take a deep breath, there will be a lot a hexadecimal numbers.

Vtables

According to the symbol table, both vtables are 32-byte wide (this is 0x20 in hexadecimal) and their addresses are:

• 0x0000000000003d68 for the vtable for Base
• 0x0000000000003d88 for the vtable for Derived

Since each line in the hexdump holds 16 bytes, we can deduce that, in the hexdump:

• Lines 1 and 2 show the vtable for Base.
• Lines 3 and 4 show the vtable for Derived.

The ABI's specification (or this presentation on slide 5) explains the content of the vtable. Let's apply this knowledge to analyze the vtables, and match the dumped bytes to addresses in the symbol tables.

For Base:

For Derived:

As you may have guessed, if there were more virtual functions, the vtables would contain more function pointers.

Typeinfo

The vtables point to the typeinfo objects, let's have a closer look at their contents.

From the symbol table, we know that:

In the hexdump of the section, we can deduce that:

• Line 5 shows the typeinfo for Base.
• Lines 6 and 7 show the typeinfo for Derived.

Once again, we can match the dumped bytes with the data from the symbol table.

For Base:

For Derived:

As you have probably guessed, the objects are implementations of std::type_info. The ABI's specification includes a dedicated section for RTTI. For in-depth details, you may explore (the somewhat esoteric) part about RTTI layout. You will see that std::type_info has several subtypes, and that __si_class_type_info is (in all likelihood) used here.

Typeinfo Names

The remaining data we haven't explored yet are the names residing in the .rodata section. This section is dedicated to store the data from our code.

$ readelf --hex-dump .rodata a.out

Hex dump of section '.rodata':
  0x00002000 01000200 42617365 203d3e20 666f6f28 ....Base => foo(
  0x00002010 29004261 7365203d 3e206261 72282900 ).Base => bar().
  0x00002020 44657269 76656420 3d3e2066 6f6f2829 Derived => foo()
  0x00002030 00446572 69766564 203d3e20 62617228 .Derived => bar(
  0x00002040 29003442 61736500 37446572 69766564 ).4Base.7Derived
  0x00002050 00                                  .

On the right side of the dump, we find the ASCII interpretation of the hexadecimal values.

Here, we see the strings printed in each function and the mangled names of the classes. Why do the mangled names contain 4 and 7? This simply corresponds to the length of the subsequent identifiers.

Disable RTTI

As a bonus, we will disable RTTI and observe the impact on the vtables.

Modify your CMakeLists.txt to add the appropriate option:

target_compile_options(a.out PRIVATE
        -O1
        -fno-rtti
)

Once the project has been recompiled, we can examine the symbol table again:

$ objdump --syms --demangle a.out | sort | egrep "Base|Derived"
000000000000116a g     F .text  0000000000000015              Base::foo() const
0000000000001180 g     F .text  0000000000000015              Base::bar() const
0000000000001196 g     F .text  0000000000000015              Derived::foo() const
00000000000011ac g     F .text  0000000000000015              Derived::bar() const
00000000000011c1 g     F .text  000000000000000e              use(Base const&)
0000000000003da0  w    O .data.rel.ro   0000000000000020              vtable for Base
0000000000003dc0  w    O .data.rel.ro   0000000000000020              vtable for Derived

The size of the vtables remains unchanged, but all symbols related to type information are now absent.

We can also examine the hexdump of the .data.rel.ro section:

$ readelf --hex-dump .data.rel.ro a.out

Hex dump of section '.data.rel.ro':
  0x00003da0 00000000 00000000 00000000 00000000 ................
  0x00003db0 6a110000 00000000 80110000 00000000 j...............
  0x00003dc0 00000000 00000000 00000000 00000000 ................
  0x00003dd0 96110000 00000000 ac110000 00000000 ................

The second double word in each vtables is now zero, to represent a null pointer, since there is no RTTI to point to.

If you dump the .rodata section, you will see that the type names are absent as well.

Conclusion

In this episode, we delved into the bytes stored in the ELF file for the vtables. Their content is mostly dictated by the Itanium ABI followed by GCC. Vtables hold a pointer to RTTI (if enabled) along with pointers to all virtual functions. This was a basic case, with a single level of simple inheritance. I may cover more advanced cases in a further episode.

In the next episode, we will explore how vtables are used at assembly level.

I will publish the episodes as I write them. Subscribe to be notified! 🥳