In this episode, we will use Docker to set up and manage our build environment.

The embedded world doesn’t always embrace the latest software development techniques. I acknowledged this in the previous episode about unit tests. Four years ago, when I started this series, I was totally unaware of Docker for instance. Since then, I have used it for non-embedded projects and I think it could have solved some issues I encountered in the past. I would like to share my experience and demonstrate that it can perfectly fit in an MCU project.

It’s been almost four years, and it’s about time to revive this series on CMake and STM32 (or MCUs in general, STM32 just serves as a tangible example).

Funny enough, I’m not working with microcontrollers anymore…. This is a very recent change in my professional career, even if I think I will probably work again with MCUs sooner or later. However, I still use CMake to build C++ projects! The real reason to resume this series is my desire to write an article Docker for builds. In 2020, I had never used Docker at all. Today, I use it very often, and I’m convinced it could have solved some build and environment issues back then.

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.

In 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 stackoverflow (the second answer is particularly enlightening).