In this section, we confront our contribution with similar publications. Although object debugging may appear surprising in this context, the presented work clearly focuses on programming model behind object-oriented programming, in contrast with the language itself. The name programming-model-centric debugging stemmed out of this work on object-centric debugging [RBN12].
Object Debugging
The authors of [RBN12] presented an object-centric debugger, which aims at shifting the debugger focus from the execution stack towards the objects themselves. Our proposal shares part of their motivations, although they considered different abstraction levels and constraints. Their solution is based on the ability to dynamically modify the behavior of individual objects, for instance to hook object instantiations, method calls, etc. and inject a debugger notification. So it required a programming language evolved enough to offer this capability, typically an interpreted language, or predefined hook points. Our work is more oriented towards low-level languages, in particular the C language which is frequently used in embedded systems. They also targeted programming language-level debugging, as they worked with programming language concepts, whereas we focused our efforts on the programming model. This means that they did not address the problem of bringing the debugger closer to the programming model abstractions used in the applications, and the developer is left with overwhelming information about low-level details. Nevertheless, their approach could be used in conjunction with ours, once the programming-model-related part of the debugging activity has narrowed down the problem search-space.
Component Debugging
General component-based application debugging presents an additional difficulty, which was out of scope of this work, as not directly relevant to embedded systems. Component frameworks usually have the ability to bring together components written in different languages and/or black-boxes, provided by third parties. In this scenario, source-level debuggers are of little help, as most of them do not support multi-language debugging, or debugging is simply not possible in case of black-boxes. The authors of [WK05] proposed a solution to this problem: they squeezed debugging compo- nents in between application components. These debugging components are able to monitor component interface activities without any knowledge about the implemen-
7.3 programming-model aware debugging tation and/or without exhibiting the multi-language debugging problem. The article described some of the features which can be achieved with this concept, which include: • Record and replay of the interactions, which allows a standalone re-execution of
a component.
• Data and flow control analyses at component level.
• Setting breakpoints on the interfaces for interactive debugging.
This approach is non-negligibly intrusive as it requires developers to build and manually connect the interface monitors (although they mentioned that future versions should be able to do it automatically). Also, as the debugging mechanisms are directly integrated in the application and certainly have a significant cost (especially in their context of scientific computing), the debug and production versions of the application are inevitably different, and this discrepancy may hide some of the bugs.
Dataflow Debugging
StreamIt is a programming language for high-performance streaming applications [TKA02], which can be related to dataflow programming models and in particular synchronous dataflow [LM87]. The StreamIt Development Tool [Kuo04] provides a graphical environment to assist stream applications coding and debugging. Its debugger is tailored to StreamIt programming language. Similarly to our approach, the debugger takes into account StreamIt specificities and allows developers to interact with a graph representation of the application. It also displays information about the communication channels, such as the tokens they hold or stream statistics.
So their tool appears to tackle the challenges we describe in Chapter 2, Section2.3.2. However, they did not focus on the problems of dynamic dataflow, as StreamIt is a synchronous dataflow language: all data must be received before execution and actors’ sending and receiving rate is defined at compile time. So a substantial part of interactive debug challenges is avoided.
Wahl et al. described in 1988 a debugging methodology for dataflow programs [WS88], which shares similarities with our approach. To our knowledge, this is the only research study available related to dataflow debugging. However, at that time, they still had faith in real dataflow machines, with non von Neumann architectures. Their methodology pointed out that they wanted “to allow the user to debug a program in a way that is close to his or her conceptual model of the program.” They also mentioned that “at the same time, the user must be supplied with a set of debugging commands that includes those with which he and she is familiar with in the context of uni-processor von Neumann machines.” We intimately share these convictions, which drove our work for this thesis.
The methodology they proposed is close to our idea of dataflow debugging, however they only skimmed over the interactive debugging aspects and they did not provide details about its actual usage. Our work on dataflow debugging extends and deepens this specific aspect. Furthermore, they explained that their methodology relies on a
related work
Figure 7.2: Gdebugger interface of OpenCL debugging.
dataflow machine simulators, which have to be modified to support debugging. This requirement strongly limits the scope of their work, as their debugging module would have to be implemented at hardware level. Our approach does not face this problem, as the debugger only interacts with the software dataflow environment.
OpenCL Debugging
Gremedy Gdebugger [Gra10] is a commercial debugger for OpenCL applications. Its graphical user-interface allows developers to control the execution based on OpenCL operations. Namely, they can set breakpoints on API functions, OpenCL errors or memory leaks. It is also possible to visualize OpenCL entities relationship and inspect the content of OpenCL buffers. Figure7.2presents different parts of the user interface, during an OpenCL debugging session.
These capabilities are interesting, although the interactive debugging side of the tool appears to be limited. Indeed, the tool can only analyze OpenCL elements, which limits the benefits for an overall application analysis and make compulsory the use of another debugger to understand the actual code behaviour. The source-level debugger they rely on is entirely hidden to the user, who cannot benefit from its capabilities.
7.4 visualization-assisted debugging