|Non-Confidential||PDF version||ARM DUI0446Z|
|Home > Introduction to DS-5 Debugger > Overview: Debugging multi-core (SMP and AMP), big.LITTLE , and multi-cluster targets > Debugging SMP systems|
From the point of view of DS-5 Debugger, Symmetric Multi Processing (SMP) refers to a set of architecturally identical cores that are tightly coupled together and used as a single multi-core execution block. Also, from the point of view of the debugger, they must be started and halted together.
DS-5 Debugger expects an SMP system to meet the following requirements:
To enable SMP support in the debugger, you must first configure a debug session in the Debug Configurations dialog. Configuring a single SMP connection is all that you require to enable SMP support in the debugger.
Targets that support SMP debugging have SMP mentioned against them.
Once connected to your target, use the Debug Control view to work with all the cores in your SMP system.
When debugging an SMP system, image and symbol loading operations apply to all the SMP processors.
For image loading, this means that the image code and data are written to memory once, through one of the processors, and are assumed to be accessible through the other processors at the same address because they share the same memory.
For symbol loading, this means that debug information is loaded once and is available when debugging any of the processors.
When debugging an SMP system, attempting to run one processor automatically starts running all the other processors in the system. Similarly, when one processor stops, either because you requested it or because of an event such as a breakpoint being hit, then all the other processors in the system stop.
The exception to this is when a nexti operation is required to step over a function call, in which case, the debugger sets a breakpoint and then runs all processors. All other stepping commands affect all processors.
Depending on your system, there might be a delay between different cores running or stopping. This delay can be very large because the debugger must run and stop each core individually. However, hardware cross-trigger implementations in most SMP systems ensure that the delays are minimal and are limited to a few processor clock cycles.
In rare cases, one processor might stop, and one or more of the other processors might not respond. This can occur, for example, when a processor running code in secure mode has temporarily disabled debug ability. When this occurs, the Debug Control view displays the individual state of each processor, running or stopped, so you can see which ones have failed to stop. Subsequent run and step operations might not operate correctly until all the processors stop.
By default, when debugging an SMP system, breakpoint, watchpoint, and signal (vector catch) operations apply to all processors. This means that you can set one breakpoint to trigger when any of the processors execute code that meets the criteria. When the debugger stops due to a breakpoint, watchpoint, or signal, then the processor that causes the event is listed in the Commands view.
Breakpoints or watchpoints can be configured for one or more processors by selecting the required processor in the relevant Properties dialog box. Alternatively, you can use the break-stop-on-cores command. This feature is not available for signals.
Views of the target state, including Registers, Call stack, Memory, Disassembly, Expressions, and Variables contain content that is specific to a processor. Views such as Breakpoints, Signals, and Commands are shared by all the processors in the SMP system, and display the same contents regardless of which processor is currently selected.
If you are using a connection that enables trace support, you can view trace for each of the processors in your system using the Trace view.
By default, the Trace view shows trace for the processor that is currently selected in the Debug Control view. Alternatively, you can choose to link a Trace view to a specific processor by using the Linked: context toolbar option for that Trace view. Creating multiple Trace views linked to specific processors enables you to view the trace from multiple processors at the same time.