Problem¶
Linking of instrumented code fails with error messages like
error: undefined reference to __cs_tb_16QpRO_1RtJv5_21IXoc_home_someone_src_input_file_cpp
The exact content of the messages depend on the linker, but they
always tell that one or more symbols beginning with __cs_tb_ are
missing.
Explanation¶
Such errors occur when code that is instrumented by Coco is linked statically to code that is not instrumented.
When object files are statically linked, either all of them must be instrumented by Coco, or none. (Dynamic linking is different: One can combine a non-instrumented DLL or shared object file with instrumented code, or vice versa.)
The __cs_tb_ file are created by Coco during the instrumentation;
they contain the internal counters with which Coco measures how often
a certain piece of code is executed. When linking, Coco expects in
every object file such a data structure, even if it does not measure
any code coverage in it. To exclude files from instrumentation, one
uses therefore --cs-exclude-file-abs-wildcard and
similar
flags
.
Finding the missing files¶
In a complex build, it can be difficult to find out which files were not instrumented. The names of the missing symbols in the error message provide here an important hint. When creating the symbol name of the instrumentation table, Coco puts the path to the source file at the end. The path must be simplified to create an admissible variable name, and Coco takes all forbidden characters (like “_”, “/”, “\” or “.") and converts them to underscores.
It is easy to revert this transformation. The symbol in the example
above therefore belongs probably to the file
/home/someone/src/input/file.cpp or possibly to
/home/someone/src/input_file.cpp. In practice, this ambiguity will
provide no problems.