Run control options
Most debuggers provide run control options, for example stop, run, and step, although the names used for these options may vary. In this section, we will discuss each of the run control options, and provide some of the implications of each.
The stop option is usually used when you want to inspect the processor or target state for debugging purposes. Stopping or halting a core will put the processor into Debug state. Debug state occurs when:
- The Processing Element (PE) stops executing instructions and control is passed over to a connected debugger.
- The debugger determines which instructions, if any, will be executed.
- The Debug Communications Channel (DCC) in the debug logic can be used to pass data between the PE and the debugger.
The core cannot service any interrupts when in Debug state.
To perform debug operations, the debugger will need to execute some instructions on the processor. These debug operations generally include:
- Reading and writing memory
- Reading and writing processor registers
- Loading Memory Management Unit (MMU) and Translation Look-aside Buffer (TLB) table entries
- Moving between Exception levels (ELs)
The instructions executed to perform debug operations will behave in the same way as any other instructions executed by the processor. This means that, when these operations are performed, subtle changes might be made to the processor state. For instance, writing to a memory address using a debugger might, in turn, generate the following:
- A new TLB entry for the address translation, which might result in TLB eviction.
- Cache lines pulled in if the address is cached, which might result in cache line evictions.
- A write request to external memory.
In most cases, these subtle changes will not affect the processor or target. However, if you are debugging a problem that is sensitive to changes in timing or caching, you should keep these possible effects in mind.
While a processor is stopped, the rest of the target devices might not stop. For instance, if a watchdog timer is running while a processor is halted, the timer might trigger due to lack of activity and reset the board while you are debugging.
When debugging, the core will usually be clocked at a much slower rate than normal. This means that some operations, like large region memory fills, will take longer to perform with a debugger.
The run option usually means that we want to start, or resume, normal processor execution. If the processor is resuming execution, the debugger needs to remove any changes that no longer apply or are visible to the user. A good example is a debugger replacing a software breakpoint that has already been hit for the original instruction, and then resetting the breakpoint when execution commences. The subtle changes that are introduced when executing instructions to perform debug operations are usually not changed back to their original state.
The step option usually means to move the current execution point down or over one instruction or one source line.
A single instruction step is achieved using a halting step debug event. A debugger uses the following operations to perform a halting step debug event:
- With the PE in Debug state, the debugger activates halting step.
- The debugger signals the PE to exit Debug state and return to the instruction that is to be stepped.
- The PE executes that single instruction.
- The PE enters Debug state before executing the next instruction.
Exceptions can be generated by the instruction being stepped, or just before or just after the instruction step occurs.
Stepping one source line involves stepping one or more instructions. You may see unusual behavior when stepping in sources files, for example:
- Only seeing a PC indicator in the assembly code but not a source file
- Stepping more source lines than you expected
The common reasons for these types of behavior are:
- Lack of debug information. As mentioned in Program load, a debugger usually needs debug information in order to display the position of the PC in a source file. If you step into a source file for which the debugger does not have debug information, the PC indicator will probably only show up in the assembly code view. This can generally be fixed by loading the source file debug information into the debugger.
- The program was built with a high optimization level. Building with a higher optimization level allows the build tools to be more aggressive about removing code that appears unnecessary. This could mean that the source lines either no longer have any instructions associated with them, or potentially have very few instructions associated with them. If this is the case, you should to investigate why there is an absence of code, or rebuild the program with a lower optimization level.
- Moved Exception levels. Some debuggers will require additional data. for example debug information, to be available when moving between different Exception levels. If the additional data is not present, the debugger may not be able to show the accompanying source files when stepping in a different Exception level.