You copied the Doc URL to your clipboard.

Debugger concepts

The following concepts are involved when debugging applications.


A debugger is software running on a host computer that enables you to make use of a debug agent to examine and control the execution of software running on a debug target.

Debug session

A debug session begins when you connect the debugger to a target or a model for debugging software running on the target and ends when you disconnect the host software from the target.

Debug target

At an early stage of product development there might be no hardware so the expected behavior of the hardware is simulated by software. This is referred to in the debugger documentation as a model. Even though you might run a model on the same computer as the debugger, it is useful to think of the target as a separate piece of hardware.

Alternatively, you can build a prototype product on a printed circuit board, including one or more processors on which you run and debug the application. This is referred to in the debugger documentation as a hardware target.

Debug agent

A debug agent performs the actions requested by the debugger on the target, for example:

  • setting breakpoints

  • reading from memory

  • writing to memory.

The debug agent is not the application being debugged, nor the debugger itself.

Examples include:

  • debug hardware agents:

    • ARM DSTREAM™ unit

    • ARM RVI™ unit.

  • debug software agents:

    • Real-Time System Model (RTSM)

    • gdbserver.


Each processor in the target can have a process currently in execution. Each process uses values stored in variables, registers, and other memory locations. These values can change during the execution of the process.

The context of a process describes its current state, as defined principally by the call stack that lists all the currently active calls. The context changes when:

  • a function is called

  • a function returns

  • an interrupt or an exception occurs.

Because variables can have class, local, or global scope, the context determines which variables are currently accessible. Every process has its own context. When execution of a process stops, you can examine and change values in its current context.


The scope of a variable is determined by the point within an application at which it is defined. Variables can have values that are relevant within:

  • a specific class only (class)

  • a specific function only (local)

  • a specific file only (static global)

  • the entire application (global).