Witekio’s engineers have broad experience in how to debug the Linux kernel, Yocto layers, and the hundreds of software dependencies that connect with these. This experience and the combined expertise of engineers in the EU, the UK, and North America means that there is often no need to resort to formal debugging tools to maintain and update code. Only when an issue falls outside of this vast experience do engineers turn to Linux debugging tools understanding, as they do, the benefits and drawbacks of using each.
Debugging tools such as JTAG (Joint Test Action Group) and GDB (GNU Debugger) are considered akin to ‘the biggest hammer’ in the Witekio toolbox. Both are high-level debugging tools and JTAG is often deemed essential when it comes to debugging embedded systems that cannot be debugged by any other channel. Yet being high-level debugging tools, they are often akin to using a hammer to swat a fly. GDB, too, while effective, lacks the detail that JTAG offers. For Witekio engineers, then, both tools are essential but to be used sparingly when other approaches prove unsuccessful or inapplicable.
KDbg is an alternative GUI debugger for the KDE Desktop Environment. It can be considered something like a more user-friendly interface to the GDB tool, making it more intuitive and potentially faster to resolve issues. Valgrind is a memory debugger that can be run on all major desktop platforms (Linux, macOS, Windows) and offers a suite of tools for analyzing embedded software. What’s more, Valgrind can also be used as a framework for creating custom dynamic analysis tools, including profilers.
Occasionally and when tracing a particularly elusive bug, Witekio engineers will also utilize a ‘print’ statement or prtmsg approach. This somewhat primitive debugging approach involves adding print statements into the software to understand a control flow, gather key variables, and identify points of failure. While effective, there are disadvantages to this approach, not least that the additions to the code will have to be removed, the code recompiled, and the software re-run to get the output. It’s time-consuming but sometimes necessary.