Task level debugging
In many cases, the use of a low level debugger is not very efficient
compared with the type of control that may be needed. A low level debugger is
fine for setting a breakpoint at the start of a routine but it cannot set them
for particular task functions and operations. It is possible to set a
breakpoint at the start of the routine that sends a message, but if only a
particular message is required, the low level approach will need manual
inspection of all messages to isolate the one that is needed — an often
daunting and impractical approach!
To solve this problem, most operating systems provide a task level
debugger which works at the operating system level. Breakpoints can be set on
system circumstances, such as events, messages, interrupt routines and so on,
as well as the more normal memory address. In addition, the ability to filter
messages and events is often included. Data on the current executing tasks is
provided, such as memory usage, current status and a snapshot of the registers.
The fundamental aim of a debugging methodology is to restrict the
introduction of untested software or hardware to a single item. This is good
practice and of benefit to the design and implementation of any system, even
those that use emula-tion early on in the design cycle.
It is to prevent this integration of two unknowns that simulation
programs to simulate and test software, hardware or both can play a critical
part in the development process.