The output shown in Figure 3 depicts excerpts from a debugging session of a program performing fast fourier transformations within the environment using the unmodified source-level debugger dbx [].
Figure 3: Annotated Excerpts from a Sample Debugging Session
First, a conditional breakpoint is set on a function call that checks for a deadline miss after 4 million cycles. The display command ensures that the elapsed time estimated in cycles is displayed at each breakpoint. The execution is stopped on line 123 after over 4 million cycles, which indicates that the task could not finish within the given deadline. This conditional breakpoint was placed on a repeatedly executed function call to periodically check this condition. The deadline miss can be narrowed down to an even smaller code portion by setting further conditional breakpoints. At program termination, the final number of processor cycles is displayed.
The timing information can be used during debugging to locate portions of code that consume most of the execution time. This information can be used to hand-tune programs or redesign algorithms.
When a set of real-time tasks is debugged, one can identify the task that is missing a deadline, either by checking the elapsed time or by setting a conditional breakpoint dependent on the elapsed time. The schedule can then be fixed in various ways. One can tune the task that missed the deadline. Alternatively, one can tune any of the preceding tasks if this results in a feasible schedule. The latter may be a useful approach when a task overruns its estimated execution time without violating a deadline, thereby causing subsequent tasks to miss their deadlines. The debugger will help to find the culprit in such situations. Another option would be to redesign the task set and the schedule, for example by further partitioning of the tasks [].