tracing with gcc

Tracing in C and C++ Tracing function calls is a general technique for debugging applications (and collecting information). When something does not work as expected, the first useful information is to know where the error happened, what’s the status of the program, and so on. Unfortunately, the most technique I’ve seen boil down to editing the called (or supposedly called) functions and add a printf call, hidden behind a macro that would add other information like function name and line number.

Read more →

fmove

What is move semantic C++11 introduced move semantic. In short, move semantics permits to make further optimization for avoiding copying data. Not only the compiler can do such optimization, but the developer itself can also hint the compiler where variables are not used anymore, and so a copy of it could be avoided. The canonical example is std::vector<std::string> create() { std::vector<std::string> collection; // since empty, suppose no allocations collection.

Read more →

Post-build static analysis - pfunct and pahole

Only after writing about Post-build static analysis, I found a nice suite of tools that can help to inspect binaries and gather information based on the debug Information. I found pahole and pfunct all from the dwarves project. The Debian package actually contains many more utilities codiff: diff-tool for comparing how changes in source affects resulting binaries ctracer: trace execution of functions dtagnames: lists tag names

Read more →

Post-build static analysis

Most analysis development tools that I’m aware of puts the emphasis on the source code (like cppcheck or the compiler), before or during compilation, or at runtime (like Valgrind, sanitizers, gcov, …​), while or after executing the executable. I’m not aware of many tools, or practices of doing a static analysis after building an executable, but without executing it (without counting reverse engineering). So I started experimenting a little bit, and see if could gather some useful information.

Read more →

Global variables in C++ libraries

While working on a big project, we noticed there where some issues while the application exited. Most of the time those issues manifested themselves as crashes, but it was not obvious which piece of code caused it. After investigating the issue for a long time, we learned that (global) constants have a lot of bad side effects we were not aware of, even if those were confined in a single translation unit.

Read more →

Arcane C++ rules, namespaces and overloads

Last week I needed to help a colleague that had a mysterious compiler error. The code, the original was split into multiple files, looked at first like this #include <iostream> namespace A { struct foo{}; } inline std::ostream operator<<(std::ostream& os, A::foo) {return os;} namespace B { struct bar{}; inline std::ostream operator<<(std::ostream& os, bar) {return os;} void fun() { std::cout << A::foo{}; } } int main() { B::fun(); } GCC, trying to helpful, presented multiple pages of diagnostic, enumerating all overload it considered for operator<<: char, int, unsigned int, short, long, float, B::bar, and many other depending on your includes like std::string, std::regex and so on (the list was very long).

Read more →