DBGMON(1spp) RISC/os Reference Manual DBGMON(1spp)
NAME
dbgmon - standalone program debugging monitor
SYNOPSIS
dbgmon [ -r ] [ args ]
DESCRIPTION
Dbgmon, the standalone debugger, is loaded with a standalone
test program or operating system. Dbgmon controls the exe-
cution of the test program with a set of commands that lets
you examine and alter both memory and registers, set break-
points, and execute programs one instruction at a time. You
may also use dbgmon in conjunction with the MIPS debugger
pdbx(1) to provide symbolic debugging of standalone programs
and operating systems.
You can manually load dbgmon with the program to be debugged
using the boot(1spp), sload(1spp), and load(1spp) commands
provided by the PROM monitor and standalone shell (sash); or
if the Ethernet boot server support is present, you may load
dbgmon automatically by the test program being debugged if
it is linked against the standalone library.
If you specify the -r flag, or define the environment vari-
able rdebug when dbgmon is booted, or you end the zero'th
(filename argument) by ending it in dbg, then dbgmon immedi-
ately enters the remote debug mode on tty(1). When dbgmon
is in remote debug mode, it expects commands over tty(1)
from the MIPS debugger pdbx. You can exit remote debugging
mode by typing a Control-C or a Control-Z on tty(1).
REGISTER NAMES
Dbgmon provides commands to display and alter the clients
general purpose registers and system coprocessor registers.
The general purpose registers can be referred to as "r0"
through "r31" or by the compiler usage names. The compiler
names and the associated "r" name are:
COMPILER R2000 USAGE
zero r0 Wired zero
at r1 Assembler temporary
v0 r2 Function value registers
v1 r3
a0 r4 Argument registers
a1 r5
a2 r6
a3 r7
t0 r8 Caller saved registers
t1 r9
t2 r10
t3 r11
Printed 1/6/92 Page 1
DBGMON(1spp) RISC/os Reference Manual DBGMON(1spp)
t4 r12
t5 r13
t6 r14
t7 r15
s0 r16 Callee saved
s1 r17
s2 r18
s3 r19
s4 r20
s5 r21
s6 r22
s7 r23
t8 r24 Caller saved
t9 r25
k0 r26 Kernel temporary
k1 r27
gp r28 Global pointer
sp r29 Stack pointer
fp r30 Frame pointer
ra r31 Return address
Special registers and system coprocessor registers can be
referred to by the following names:
NAMES R2000 REGISTER
mdlo Mul/div register lower word
mdhi Mul/div register higher word
pc epc Exception PC
sr Status register
cause Cause register
tlbhi entryhi TLB entry hi register
tlblo entrylo TLB entry lo register
badvaddr Bad virtual address
index inx TLB index register
context ctxt Context register
random rand Random register
See the MIPS RISC Architecture manual for a description of
these registers.
FIELDING BREAKPOINT EXCEPTIONS
Because the R2000 processor does not have separate exception
addresses for breakpoints and other exceptions, the client
process must field breakpoint exceptions and forward them to
dbgmon. Fielding of breakpoints is done automatically: if
you link your program against the standalone library and use
the standalone library fault handler; or if you compile
operating systems with debugging options enabled.
The routine "exceptnorm" in the SPP source file
"saio/faultasm.s" is an example of how control can be passed
Page 2 Printed 1/6/92
DBGMON(1spp) RISC/os Reference Manual DBGMON(1spp)
back to the debug monitor when a breakpoint is fielded.
Note that the client learns which address in the debug moni-
tor to transfer to by examining the restart block field
"rb_bpaddr". See restart(5spp) for more details on the res-
tart block.
Before transferring to the address in rb_bpaddr, the client
should restore all registers except k0 and "at". Save the
register "at" in k0 and jump to the address in rb_bpaddr
using the "at" register. Keep in mind that it is difficult
to save all registers without providing TLB mappings to
allow 16 bit addressing relative to the zero register, to
avoid this requirement you cannot save register k0. Because
this register is used only by the operating system under
very restricted conditions, the loss of the contents of k0
is considered acceptable.
TRANSLATING CLIENT VIRTUAL ADDRESSES
Because the TLB at any particular time does not map the
entire set of translations that a client process can estab-
lish, the debug monitor cannot reference memory in terms of
client virtual addresses. Test programs can offer to
translate virtual addresses for the debug monitor by putting
the address of a routine that convert a kuseg or k2seg
address into a k0seg or k1seg address in the restart block
field "rb_vtop".
If the debug monitor is sent an address stored in kuseg or
k2seg and rb_vtop is non-null, then the debug monitor calls
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".
SEE ALSO
dbx(1), prom(1spp)
Printed 1/6/92 Page 3