1.3.1 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:

  • The same ELF image running on all processors.
  • All processors must have identical debug hardware. For example, the number of hardware breakpoint and watchpoint resources must be identical.
  • Breakpoints and watchpoints must only be set in regions where all processors have identical physical and virtual memory maps. Processors with separate instances of identical peripherals mapped to the same address are considered to meet this requirement. Private peripherals of ARM® multicore processors is a typical example.

Configuring and connecting

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.

Figure 1-1 Versatile Express A9x4 SMP configuration
Versatile Express A9x4 SMP configuration

Once connected to your target, use the Debug Control view to work with all the cores in your SMP system.

Image and symbol loading

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.

Running, stepping, and stopping

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.

For instruction level single-stepping commands, stepi and nexti, the currently selected processor steps one instruction.

Figure 1-2 Core 1 stopped on stepi command
Core 1 stopped on step i command

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.

Breakpoints, watchpoints, and signals

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.

Examining target state

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.


The indexes in the different Trace views do not necessarily represent the same point in time for different processors.
Non-ConfidentialPDF file icon PDF versionARM DUI0446Z
Copyright © 2010-2016 ARM Limited or its affiliates. All rights reserved.