Colocaciones, locuciones y compuestos sintagmáticos

Finally, as the instructions of any application are eventually written in a standard programming language and executed by the processor like traditional code1_{, language-} based and low-level debugging commands should still be available. Indeed, although some bugs may lay in the programming-model related aspects of the application, there is a chance that the problems are hidden deep down in the language instructions. So, memory and processor inspection, breakpoints and watchpoints (maybe entity-specific) and other step-by-step execution control primitives should be directly available. 3.1.4 Open Up to Model and Environment Specific Features

Different programming models do not provide the same functionalities, not do they require the same debugging capabilities. Therefore, programming-model centric debug- gers should adapt their debugging features to the specifics of the programming models and environments they are targeting. At this stage we can only provide hints about such features, but Section3.3and later Chapter6provide more detailed examples.

• Debuggers can follow messages transmitted from entity to entity, either based on a model-defined routing table for the entity being considered, or through user-provided tables;

• Debuggers can check user-defined constraints on the graph topology, on message payload, paths, etc., and stop the execution in case of violation.

More advanced features can also be designed thanks to the strong programming- model knowledge achieved by the debugger:

• Debuggers can detect deadlock situations with loops in the graph of blocking communications;

• If the debugger supports non-stop debugging [SPA+_{08], “smart” breakpoints can}

stop the tasks trying to communicate with tasks already stopped by the debugger, in order to limit the intrusiveness.

In the following section, we delimit the scope of applicability of this approach. 3.2 scope of applicability

Model-centric debugging can be applied to various kinds of targets. Its primary objective is task-based programming models for multicore processors. Indeed, such tasks should communicate with each other and form, implicitly or explicitly, a graph. They should also be executable in parallel. Component and dataflow programming perfectly fit in this area.

contribution: programming-model centric debugging

However, the scope of application is broader than that, as we demonstrate later in this chapter with kernel-based programming. Any programming model defining an abstract machine complex enough may benefit from this approach. And, as explained in the previous chapter, the notion of abstract machine is loosely defined, on purpose. Thus, model-based debugging can be applied on top of any API, provided that someone devotes time to its implementation.

We can exemplify this last point with a video decoder, where a model-centric debugger could recognize the different modules (e.g., sound decoder, beginning/end of a frame, the error channel, etc.). This would help developers to understand more rapidly the current state of the execution: decoding frame N, previous frame dropped, error channel empty, etc.

On the other hand, it is important to note that we only focused on a particular aspect of multicore computing: analyzing the cooperation between entities running in parallel. We do not address the problem of debugging a large number tasks, neither the time-related challenges of concurrent executions.

The main reason for that is that we believe that interactive debuggers are not suitable for this kind of problems. Indeed, for the former aspect, the quantity of information developers can understand at each step of the execution limits the possibilities of interactive debugging. If thousands of tasks are running concurrently, developers cannot go through all of them and verify that their state matches their expectations. Designing tools offering such capabilities is another research topic. Instead, they should try to narrow the problem down to a minimum size, both in term of number of parallel executions and processing time. Time-related issues are well-studies, although not yet solved. Limiting the intrusivity of interactive debugging, and furthermore improving it for such problems is yet another independent research topic.

For similar reasons, we do not target SIMD parallel computing. For such applications, a simple alternative would consist in running the code sequentially and use traditional debugging tools (or model-centric, if applicable).

Finally, the industrial context of this thesis set an additional constraint to the scope, which was that the work should focus on applications scaled for the companies’ embedded boards. This implied embedded multicore MPSoC platforms, but not large-scale, HPC-like computers.

Now that we have delimited the scope of applicability, we present, in the next section, how the principles of model-centric debugging apply to our three programming models. 3.3 how does it apply to different programming models?

The principles of model-centric debugging presented in Section3.1 are generic and independent of a particular programming model. In this section, we explain how we specialized and applied these principles to our three MPSoC programming mod- els. For each of them, we highlight different benefits of model-centric debugging: dynamic architecture reconfiguration and message exchange of component-based ap-

3.3 how does it apply to different programming models?