dbgmon − standalone program debugging monitor [ -r ] [ args ] is the MIPS standalone debugger.  Dbgmon is intended to be loaded co-resident with a standalone program or operating system and control the execution of that program.  The program being debugged is referred to as the "client" in dbgmon documentation.  Dbgmon provides commands to examine and alter both memory and registers, set breakpoints, and execute programs one instruction at a time.  Dbgmon may be used in conjuntion with the MIPS debugger to provide symbolic debugging of standalone programs and operating systems.  Dbgmon may be manually loaded co-resident with the program to be debugged via the and commands provided by the prom monitor and standalone shell; or if ethernet boot server support is present, dbgmon may be loaded automatically by the program being debugged if it has been linked against the standalone library.  If either the -r flag is specified, the environment variable "rdebug" is defined when dbgmon is booted, or the zero’th (filename) argument to dbgmon ends in ".dbg", dbgmon will immediately enter remote debug mode on tty(1).  When in remote debug mode, dbgmon expects commands via tty(1) from the MIPS debugger pdbx.  Remote debugging mode may be exited by typing a Control-C or a Control-Z on tty(1).  Dbgmon provides commands to display and alter the clients general purpose registers and system coprocessor registers.  The general purpose registers may be referred to as "r0" through "r31" or by the compiler usage names.  The compiler names and the associated "r" name are:

COMPILERR2000USAGE
zeror0Wired zero
atr1Assembler temporary
v0r2Function value registers
v1r3
a0r4Argument registers
a1r5
a2r6
a3r7
t0r8Caller saved registers
t1r9
t2r10
t3r11
t4r12
t5r13
t6r14
t7r15
s0r16Callee saved
s1r17
s2r18
s3r19
s4r20
s5r21
s6r22
s7r23
t8r24Caller saved
t9r25
k0r26Kernel temporary
k1r27
gpr28Global pointer
spr29Stack pointer
fpr30Frame pointer
rar31Return address

Special R2000 registers and system coprocessor registers may be referred to by the following names:

NAMESR2000 REGISTER
mdloMul/div register lower word
mdhiMul/div register higher word
pcepcException PC
#defineEBADF9/* Bad file number*/
#defineECHILD10/* No children*/
#defineEAGAIN11/* No more processes*/
#defineENOMEM12/* Not enough core*/
#defineEACCES13/* Permission denied*/
#defineEFAULT14/* Bad address*/
#defineENOTBLK15/* Block device required*/
#defineEBUSY16/* Mount device busy*/
#defineEEXIST17/* File exists*/
#defineEXDEV18/* Cross-device link*/
#defineENODEV19/* No such device*/
#gister
causeCause register
tlbhientryhiTLB entry hi register
tlbloentryloTLB entry lo register
badvaddrBad virtual address
indexinxTLB index register
contextctxtContext register
randomrandRandom register

See the R2000 Processor User’s Manual for a description of these registers.  Because the R2000 processor does not have separate exception addresses for breakpoints and other exceptions, the client process must be prepared to field breakpoint exceptions and forward them to dbgmon.  Any program linked against the standalone library and using the standalone library fault handlers will have this service provided.  The UMIPS operating systems compiled with debugging options enabled also provide this service.  The routine "exceptnorm" in the SPP source file "saio/faultasm.s" is an example of how control may be passed back to the debug monitor when a breakpoint is fielded.  Note that the client learns the appropriate address in the debug monitor to transfer to by examining the restart block field "rb_bpaddr".  See for more details on the restart block.  Before transfering to the address in rb_bpaddr the client should have restored all registers except k0 and "at", "at" should be saved in k0 and the address in rb_bpaddr should be jumped to via the "at" register.  Note that it is difficult to save all registers without providing tlb mappings to allow 16 bit addressing relative to the zero register, to avoid the requirement register k0 can not be saved.  Since this register should only be used by the operating system under very restricted conditions, the loss of the contents of k0 is considered acceptable.  Because the TLB at any particular time does not map the entire set of translations that a client process can establish, the debug monitor can not in general reference memory in terms of client virtual addresses.  Clients can offer to translate virtual addresses for the debug monitor by putting the address of a routine which will convert a kuseg or k2seg address into a k0seg or k1seg address in the restart block field "rb_vtop".  If the debug monitor is presented with a address lying in kuseg or k2seg and rb_vtop is non-null, the debug monitor will call the routine pointed to by rb_vtop with the virtual address as the argument.  This translation routine should assume that the virtual address refers to the process identifier currently in the system coprocessor register "entryhi".  The MIPS symbolic debugger, pdbx, can be used with the debug monitor in two modes: "automatic loading" mode allows pdbx to initiate loading both the client standalone program and the debug monitor onto the target system.  This mode requires a serial line between the host system and the remote console port on the target, ethernet support on both the target and host systems, and the boot file server daemon, bfsd, on the host system.  The "manual loading" mode requires manually loading the client program and the debug monitor, but only requires a serial line connection between the host and the remote console port on the target.  Using pdbx with the debug monitor will require a serial line connection between a serial i/o port on the M/500 host system and the remote ("b") console port on the target system.  The following adapter must be placed on an M/500 serial i/o port to connect the serial port to the target system remote port:

SerialR2300
PortPort B
2 --------------- 2
3 --------------- 3
7 --------------- 7
8
|
20

This adapter routes carrier detect, which is asserted on the M/500 serial i/o port to data terminal ready on the M/500 serial i/o port.  Data terminal ready must be asserted at the M/500 serial i/o port for and to open the port.  Should this adapter not work, it may be necessary to connect pin 2 on the serial port to pin 3 on the remote port and pin 3 on the serial port to pin 2 on the remote port.  Once the physical connection has been made between the two systems, an entry should be made in the file /etc/remote to describe the connection.  An entry of the following form is generally sufficient:

debug:dv=/dev/ttyh3:br#19200:el=^C^S^Q^U^D:ie=%$:oe=^D:

The field "dv=/dev/ttyh3" should be edited to reflect the M/500 port you have chosen to link the two systems.  The field "br#19200" should be edited to reflect the baud rate you set the remote console port to.  You should also check that serial i/o port you have chosen is marked as "off" in the file /etc/ttys, e.g.:

ttyh3"/etc/getty std.9600" wyse75 off secure

and that the line is readable and writeable by everyone, e.g.:

crw-rw-rw-  1 root  wheel  8, 3 Dec  9 17:33 /dev/ttyh3

Once the line is connected and the files set-up as described above, it should be possible to use to communicate with the remote system.  You should set the remote console baud rate (on the target system) to match the value in /etc/remote and enable the remote console, e.g.:

>> setenv rbaud 19200
>> enable tty(1)

Now you should verify the connection between the systems by using to communicate from the host system to the prom monitor on the remote system, e.g.:

% tip debug

To use automatic loading mode, the target system must have the remote console port enabled and set to a baud rate consistent with the baud rate specified in the file /etc/remote.  The target machine should also have the environment variable, "netaddr" set to the internet address of the target node.  Note that if "netaddr" is changed or the ethernet controller of the target system is replaced, ARP mappings may have to be purged on the host system.  It is a good idea to verify that you can use the device to boot from the host system (try "boot -f bfs()HOST:dbgmon").  If this fails insure that the bfsd program is running on the host and that dbgmon resides in the directory specified via the -d option when bfsd was initiated.  Once these prerequisites are established, "cd" to the directory where the object module to be debug resides and create a symbolic link between the name of the module with an appended ".dbg" and the object module to be debugged.  (e.g. ln -s prog prog.dbg).  In order to indicate to pdbx the appropriate serial port to communicate with the target system you must specify the system name, as indicated in the file /etc/remote, either by setting the UMIPS shell environment variable to the /etc/remote name or by setting the pdbx variable to the /etc/remote name before giving the pdbx run command.  The value of the pdbx variable will override the value of the environment variable Now run pdbx specifying the name with the appended .dbx as the module to be debugged.  (If you forget the .dbg suffix, the program being debugged will not automatically establish communication with pdbx.)  If you have a terminal attached to the local port when the pdbx run command is given you should see pdbx communicate with the prom monitor via the remote port and issue a command to boot the object module off the host system.  Once this module is loaded, the debug monitor should also be loaded, it should enter remote debugging mode and the client process should begin execution.  To summarize the steps for automatic mode: 1 Establish a serial line between a serial i/o port on host machine and remote console port (port b) on remote system.  the remote console port.  Verify the connection with 2 Insure that remote system has valid "netaddr" and is connected to Ethernet.  Host system should have entry for remote system in /etc/hosts and boot file server should be running.  The dbgmon object module should reside in the bfsd root directory (typically, /usr/bfsd).  Verify connection by using to load dbgmon from host.  3 Cd to directory on host where sources and object module for program to be debugged resides.  Symbolically link a file with ".dbg" suffix to object module.  4 Set environment variable "PDBXPORT" to remote system’s name as indicated in /etc/remote.  5 Run pdbx on the host system giving the .dbx suffix with the name of the object module to be debugged.  As in the automatic mode, you should first verify via tip that a serial connection can be established with the remote console port.  Once you can communicate with the remote port, download the program to be debugged (using a name without a ".dbx" suffix) by using one of prom monitor commands or The and transfer files via running on the host.  If the boot command is used, specify the -n option to avoid transfering control to the booted program.  Next load dbgmon by one of the same commands.  This time, though, omit the -n option for the boot command or perform a command to tranfers control to the debug monitor.  The debug monitor should print its name and version and then print a prompt.  Using the dbgmon command set the program counter (pc) to the entry point of the program to be debugged and enter the command "debug tty(1)", (see for more information on the debug command).  Once the debug command is given to dbgmon it enters remote debugging mode and begins to listen on tty(1) for remote debugging commands.  At this point pdbx should be initiated on the host system, specifying the serial port as indicated above and the object module to be debugged (without the ".dbx" suffix).  Once pdbx has initialized itself you must enter the pdbx command "debug 8", this command indicates to pdbx that the program to be debugged has already been loaded and it should not give the commands to load the image.  If you will be always working in the manual loading mode, you may want to put the debug 8 command in your .dbxinit file.  After issuing the debug 8 command, you may perform any other pdbx commands.  You initiate the program to be debugged with the pdbx "run" command.  In manual mode, arguments may not be passed to the program being debugged via the pdbx run command.  Arguments may only be passed to the program being debugged in manual mode when the command is used to load the debug monitor.  In this case, the debug monitor will pass any arguments it was booted with to the program being debugged.  To summarize the steps for manual mode: 1 Establish serial line between serial i/o port on host machine and remote console port (port b) on remote system.  the remote console port.  Verify connection with 2 Cd to the directory on the host where the sources and object module for the program to be debugged resides.  Download the object module (without the .dbg suffix) to the remote system.  Downloading may be done via any of or prom monitor commands.  To use or you will need to run on the host system.  If using the command, bfsd must be running as indicated in the "automatic" section above and you should specify the -n option to the boot command.  3 Download dbgmon using any of the methods described above.  Initiate dbgmon on the remote system by giving the prom monitor command or not specifying the "-n" option on the boot command.  The debug monitor should print its prompt "DBG: " on the consoles of the