
Universal Debugger Interface Specification
1-1
Chapter 1
1
Introduction to the Universal Debugger Interface (UDI)
This chapter describes the terms used in this specification to describe various
parts of the overall solution the Universal Debugger Interface (UDI) provides,
the problems that UDI attempts to solve, and the fundamental concepts used to
solve those problems.
UDI Terms
This specification refers to the debugger as the Debugger Front End (DFE).
Early conversations about UDI revolved around splitting the debugger into a
front–end (user interface) and the target interface (execution interface). This
target interface later became known as the target interface process (TIP).
Referring to it as a process implied that the TIP was not linked with the DFE
into a single executable. UDI exclusively specifies the interface between the
DFE and the TIP. The term
target
refers to the actual execution vehicle that
runs the program under control of the DFE, via the TIP. Only the TIP knows
how to control the target.
Host
refers to the computer system on which the DFE resides. Usually, the TIP
also resides on the host, but the communications method defined for some
hosts may allow the TIP to reside on a different computer system. Throughout
this document, we assume the TIP and DFE run on the same computer (i.e.,
the host).
Problems UDI Solves
In many cases, a company provides multiple debuggers, targets, or both. The
problem such a company faces is that any time an update is made to a
complicated debugger, it must be rebuilt with the code that allows it to
communicate with each of the possible targets. All debugger/target
combinations must be retested and updates supplied to all affected customers.
Additionally, end customers of embedded systems inherently want to use
debuggers with their custom hardware. While in–circuit emulators have been
one solution to this problem in the lab, many customers would like to attach a
debugger to their hardware without an in–circuit emulator. Often, that
debugger does not support the only communications path to the hardware.