About debugging bare-metal symmetric multiprocessing systems
DS-5 Debugger supports debugging bare-metal Symmetric MultiProcessing (SMP) systems. The 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 memory maps, both physical and virtual. Processors with different instance of identical peripherals mapped at the same address are considered to meet this requirement, as in the case of the private peripherals of ARM multicore processors.
Configuring and connecting
To enable SMP support in the debugger you must first configure a debug session in the Debug Configurations dialog. Targets that support SMP debugging are identified by having SMP mentioned in the Debug operation drop-down list.
Configuring a single SMP connection is all you require to enable SMP support in the debugger. On connection, you can then debug all of the SMP processors in your system by selecting them in the Debug Control view.
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, stopping and stepping
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 processors in the system stop.
For instruction level single-stepping (
nexti commands), then the currently selected processor steps one instruction. The exception to this is when a
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 one processor running or stopping and another processor running or stopping. This delay can be very large because the debugger must manually run and stop all the processors individually.
In rare cases, one processor might stop and one or more of the others fails to stop in response. 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 that 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
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.
When you are using a connection that enables trace support then you are able to view trace for each of the processors in your system. 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 Trace views do not necessarily represent the same point in time for different