Category Archives: Programming

LCOV with LLVM

The Linux package lcov is a set of Perl scripts to convert gcov coverage information into nice looking HTML pages wherein the project’s coverage metrics are concisely visible. Fortunately, the Clang compiler is also capable to generate GCOV-compatible data such that lcov may be used with the LLVM tool chain. To get LLVM working together with lcov, the following steps have to be performed:

  1. Get the latest version of lcov, at least 1.12 from the project’s web page
  2. Follow the instructions here

C++ Factory Method with Shared Libraries

Suppose that you are working on a generic framework and you would like to allow the users of the framework to extend the framework with domain-specific functionality. A programming pattern that is typically deployed for this scenario is the so-called factory method pattern. The core components of this pattern are an (abstract) interface class, a set of derived classes and a factory method that generates the requested type cast to the interface class. A very simplistic coding of the factory method could be the following:

If you are working on a very small, possibly company-internal, framework, it might be acceptable to share your complete code base with all programmers and allow them to modify the above code when adding new type classes, e.g. ClassC, ClassD, etc. In turn, if your code base is fairly huge, e.g. with overall build-times larger than 30mins, or if you do not want to share the code base, e.g. due to IP restrictions, you might want users of your framework to provide the functionality for new types in terms of shared libraries built out-of-source and loaded at runtime when requested. This post sketches how this could be implemented for the prototypical use-case above in C++.

The first ingredient for our recipe is the interface definition which is the Interface class plus an evil registration macro to streamline and unify the plugin handling:

As we will see in the later course of this post, every shared library is required to have a unique and identical entry point to be loadable by our framework. This entry point is created by the macro PLUGIN_CLASS. Note the use of extern “C” that disables the C++ name mangling such that the function is exported as createPlugin. Every plugin is required to use the macro PLUGIN_CLASS once! Given the interface, we next define our shared library for ClassA:

Next, we compile the above code as shared library and inspect the exported symbols of the shared library with the nm(1) utility to check that our entry point is available:

Note that the capital T – for text – in the output of nm(1) indicates a defined and exported function. Having defined the prerequisites for our framework, we now take a look at the new factory method:

The main function is the same as before with the sole exception that our main program requires the file name of a shared library to be given as first program argument. The new factory method factoryMethod requires the file name of the shared library to be given, but still returns a unique pointer to the Interface class. Inside the factory method, the central parts are the calls to the functions dlopen(3) and dlsym(3) that allow to load a shared library at runtime and to query for a symbol’s address inside this library, respectively. But let’s look at the code line by line. In order to map the function’s address to C++ function pointers, i.e. std::function, we define the function signature (line 6) and the respective std::function type (line 7). The shared library is then opened in line 10 by dlopen(3) which returns an opaque library handle. The first parameter to dlopen(3) is the path or file name of the shared library, while the second parameters configures when unresolved symbols inside the shared library are tried to resolve. The two possible settings are RTLD_LAZY to perform the resolution only when the symbol is referenced or RTLD_NOW to perform the resolution immediately at load time. We choose the former one for performance reasons. In line 14 we finally query the shared library, identified by the opaque library handle, for the address of the function createPlugin which is cast to the std::function in line 16 and eventually called in line 17.

Compiling and running the code then yields the desired results:

Simplistic GNU makefile for lazy programmers

A friend of mine and I, we were recently discussing about the layout of a GNU makefile that allows you to add source files to your source tree in an arbitrary directory hierarchy without having to modify the makefile. As other requirements, we only wanted to create a single top-level makefile in the build directory, though no cascading sub-directory makefiles, and the makefile should be able to handle multiple source files with the same name.

Beside the usual make logic, GNU make provides the makefile writer with a good set of helper functions, e.g. for text replacement or directory/file operations. For a full reference of GNU make functions, please check out the official documentation.

As mentioned in the title, this makefile is very simplistic. It makes the following assumption about the software project. It is for now basically oriented towards software development in C, but it should be easy possible to enhance it for other languages.

  • all the source files are located in a single directory, e.g. src
  • there is a separate build directory containing the created object files, e.g. build (this is not a hard requirement, but I like to separate the sources from the object and executable files
  • all source files having the same file type will be built with the same compiler options

So, here it is:

So, what is this makefile doing?

The first line collects all the source files, in this case all C source files, from the source directory. The $(shell …) command will execute any shell command from within the makefile. These specific shell commands will only record the file path relative to the source directory. I will explain below why this is useful. The second line is a text replacement to determine the object files corresponding the source files.

The next interesting line is the vpath command. The vpath command allows the makefile writer to specify directories where make should look for dependencies in addition to the local directory. It furthermore allows you to specify alternative directories based on the file extension. Here, we say that make should also look for .c files in the source directory.

Finally, the most important part of the makefile is the generic rule to translate .c files into .o files (%.o: %.c). This rule is used for each object file requested as dependency for the final executable (bin). For example, assume that the final executable only depends on the object file generic/a/bin.o, then GNU make will internally handle the generic rule as:

The next important aspect here is that we use the special make variables $< (refering to the first dependency) and $@ (refering to the target). This rule is also where the vpath instruction from the beginning of the makefile comes into play. When searching for the file generic/a/bin.c as dependency, GNU make will first try to find this file relative to the current directory, but since it does not exist relative to the local directory, it will then search relative to the vpath directory, though the source directory. There, GNU make will find the file and use it. As a short side note about this rule: the $(dir …) make function extracts the directory part of a file name and the dash (-) in front of the rule tells make to ignore the return value of the mkdir command. This is a somewhat nasty hack, but simplifies the makefile by avoiding checks for directory existence.

As said, this makefile is very simplistic and might not match all requirements. However, it at least shows some interesting aspects and functions of GNU make.