EN 
DE The future of debugging technologies
Author: André Schmitz, Green Hills Software
Contribution – Embedded Software Engineering Congress 2015
Debugging with `printf()`, setting breakpoints, and step-by-step code execution are debugging methods of the past. Today's debugging tools can already do much more, such as automatic runtime error detection, heap analysis and memory leak detection, profiling, and, last but not least, the evaluation of hardware trace data. But what will the future hold? How will we be able to debug complex software on multi-core systems that access numerous peripheral components quickly and easily? How will collaborative error detection be conducted within a team? Which methods will help us save time in our work? This paper presents the current state of the art and provides an outlook on new methods and technologies that will make debugging easier in the future.
State of the art
Debugging today is more than just single-stepping, breakpoints, and memory views. Tools for static code analysis and MISRA checkers already exist, capable of analyzing code and identifying potential errors even before its first execution. This is the most cost-effective way to find software bugs. Automatic code generation is also a significant step towards error-free code.
When the program is executed on the target, various methods can be used to easily find errors in the program. Profiling (see Figure 1, PDFFor example, it makes it easy to identify the program's hotspots and decide where further optimization is needed. Runtime debugging allows you to use the compiler to build check sequences into the code, which can then be used to automatically find errors. These errors include, for example, exceeding array boundaries, exceeding the range of variables, division by zero, or dereferencing a null pointer.
When it comes to using dynamic memory, current tools can automatically display all heap reservations, identify accesses to unallocated memory, and, last but not least, automatically detect all memory leaks. There are also tools for analyzing the temporal behavior of a system, logging and visualizing all relevant events.
Another important aspect of debugging is simulation. For example, code can be executed on simulated controllers, or the behavior of the sensors and the environment of the embedded system can be simulated (REST bus, hardware-in-the-loop [1], etc.). Tools exist that can automatically generate module and integration tests to ensure good test coverage and test documentation.
The „three-pillar model“
A holistic test management approach is characterized by several aspects in order to cover all relevant tests within a project cycle. The first pillar is the Test strategy, which specifies how the project will proceed in concrete terms. The second pillar forms a suitable Test methodology, which are based on the Test strategy builds up. The Test methodology This primarily includes a selection of different test procedures and test systems. The third pillar is test management within the projects. The central role here is played by the Test Manager one. He is responsible for creating a suitable Test strategy and Test methodology for the respective project.
Many controllers have an integrated trace unit, allowing you to collect and efficiently process trace data using appropriate trace tools. Furthermore, these tools enable you to debug backward in time, essentially traversing the trace data by moving the program counter forward and backward in the debugger, displaying variables and registers as usual (see Figure 2)., PDF)
Challenges of the future
Looking further into the future, we must prepare ourselves for an increasing number of multi-core CPUs with ever-higher clock speeds. Current high-end CPUs come with 4 or 8 cores and a clock speed of more than 2 GHz [2] [3]. This trend will certainly continue, and it will almost be irrelevant whether the number of cores or the frequency grows faster.
But how do we get the trace data from an 8-core 2GHz CPU to trace hardware? Will we have tools that allow us to analyze concurrent applications on 8 or more cores over a long period?
It is foreseeable that we will have more and more heterogeneous hardware and software. The goal here is to be able to debug different operating systems simultaneously on a single hypervisor, or on different cores of the same architecture (Cortex-M4 and Cortex-A9), or even combinations of completely different hardware architectures.
Another interesting problem will be the analysis of software-hardware interaction. For example, there is a tool for nVidia GPUs called Nsight [4], which can visualize the processes on the GPU and in the program code during scene rendering and allows for efficient analysis. The tool clearly demonstrates the interaction between CPU and GPU. However, such tools are currently only available for PCs, not for embedded systems.
Regardless of what actually happens, we will definitely need to be able to handle ever-increasing amounts of data and search, analyze, and visualize it quickly and efficiently. Ultimately, we also need to ask ourselves how we can find software bugs faster. This requires, first and foremost, a rethink and optimizations in the development process.
Looking to the future
Let me formulate the outlook for the future in the form of questions.
Wouldn't it be great to be able to efficiently visualize large amounts of data, allowing you to see at any time exactly what your program is doing or has done? Of course, this requires fast tools on your workstations. Nvidia's Nsight tool is optimized for analyzing PC programs—that is, programs running on the same PC as the tool. Wouldn't it be wonderful to be able to use similar tools for embedded systems? We could then run highly complex software systems in such a way that all processes, both inside and outside the system, could be identified and correlated in minute detail. Perhaps this will require new simulation environments, the likes of which we don't yet have.
Are we fast enough at identifying the cause of a software error? If we manage to optimize our processes and tooling so that the time from the occurrence and detection of a software error to finding and fixing the defective code becomes ever shorter, then this will increase productivity immensely. We will also be able to easily debug increasingly complex software systems.
How are we supposed to work in increasingly larger software teams in the future if ever more complex software produces ever more obscure bugs? If a tester finds a difficult-to-reproduce bug, they must be able to provide the developer with an environment in which the problem can be reproduced in the shortest possible time, as well as identify and fix the bug.
Summary
The challenges in troubleshooting software bugs will be:
- Processing large amounts of data
- Minimizing the time from the occurrence of an error to its correction
- Efficient collaboration in software teams
We need new concepts, technologies and tools to increase the productivity of software developers.
References
[1] https://de.wikipedia.org/wiki/Hardware_in_the_Loop
[2] https://de.wikipedia.org/wiki/Intel_Atom
[3] https://de.wikipedia.org/wiki/ARM_Cortex-A
[4] https://www.nvidia.com/object/nsight.html
Testing, Quality & Debugging – Our Training & Coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topics of testing, quality & debugging.
Training & coaching on the other topics in our portfolio can be found here. here.
Testing, Quality & Debug – Expertise
Valuable expertise on the topics of testing, quality & debugging is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
