The software debug environment consists of a number of software modules that must be present to support debugging. Some of these will also be present in the final game system, but many will not. A good understanding of the software architecture will enable the game developer to deal with unexpected situations that arise during a debugging session.
At the highest level, the debugger consists of two major parts. On the development host, a graphically oriented source level debugger called gvd is provided. In the target system, a small in-circuit debug monitor called rmon acts as the agent for gvd. The operator of the debugger sees only gvd, but requests are actually fulfilled by rmon. That is, you may open a window on the host for the purpose of looking at memory contents. The host cannot access such memory directly, but it can ask rmon to fetch the memory contents from the target so that the host can display them. rmon runs as three threads under the OS, but these threads spend most of their time either blocked (awaiting a host request) or stopped. Thus, they do not interfere with the operation of the game (other than taking up some memory) unless they are processing debugging commands under operator control.
Like the OS and other library routines, rmon is included in a build only if the game developer specifically asks for it. This is done by creating a thread with rmonMain specified as the function to be started when that thread is run. The rmon program is part of libultra, the Nintendo 64 run-time library. You do not need to have any special files to include rmon in a build. Referencing rmonMain automatically includes all code and data for all three of rmon's threads.
On the host side, the main program you see is gvd, the debugger. However, there are a number of support programs that run in conjunction with the debugger. Since gvd is designed to work in other environments as well, it uses a separate program called dbgif (for debugger interface) to communicate with the target environment. Only dbgif knows the actual means of communication with the target system; gvd is independent of such concerns.
Since we wish to share the GIO interface between the host and target with other programs (for example, diagnostics), a third module is provided on the host. This is a device driver built into the UNIX kernel, and functions as the target manager. When any program (such as dbgif) wishes to communicate with the target, it issues requests to the N64 device driver. In this way, it is possible for two pairs of programs running on the host and target to communicate through a single channel without interference.