October 13 1995, Draft 1
361
Chapter 7 Software Debugging
could construct their own communications module, for some special hardware com-
munications link, as long as it complied with the standard.
7.5.2 UDI Specification
If UDI were a specification at procedural level, then debugger developers and
communication module developers would have to supply linkable images of their
code so the debug tool combination could be linked by the intended user. This is un-
desirable because it would require a linked image for every tool combination. Addi-
tionally, the final linked program would be required to run on an single debug host.
UDI actually relies on an interprocess communication (IPC) mechanism to connect
two different processes. The debugger is linked into an executable program to run on
the host processor, this process is known as the Debugger Front End (DFE). The com-
munications module is linked as a separate process which runs on the same or a dif-
ferent host processor, this process is known as the Target interface Process(TIP). The
two processes communicate via the UDI interprocess communication specification.
Two IPC mechanisms have so far been specified: one uses shared memory and is
intended for DOS developers, the second uses sockets and is intended for UNIX and
VMS developers. Of course, when the shared memory IPC implementation is used
the DFE and TIP processes must both execute on the same host processor. Using
sockets with Internet domain communication enables the DFE and TIP to each
execute on separate hosts on a computer network. Thus an applications developer
can, from the workstation on his desk, debug a target processor which is connected to
a network node located in a remote hardware lab. Using sockets with UNIX domain
addresses (the method used to implement UNIX pipes) enables both processes to run
on the same host.
Some of the currently available UDI conforming debug tools are presented in
Figure 7-9. The interprocess communications layer defined by UDI enables the ap-
plications developer to select any front end tool (DFE) with any of the target control
tools (TIP).
Because developers of UDI conforming tools must each have code which inter-
faces with the IPC mechanism according to the UDI protocol, the UDI community
freely shares a library of code know as the UDI–p library. This code presents a proce-
dural layer which hides the IPC implementation. For example, consider the follow-
ing procedure:
The DFE code calls the UDIRead function which
transports
the function call to
the TIP process. The TIP code developer must resolve the function request, by adding
code which is specific to controlling the particular target. The IPC layer is effectively
transparent, the TIP developer is unaware that the procedure caller is from a different
process, possibly on a different host machine. Table 7-2 lists most of the UDI–p pro-
cedures available.