When requested, the kernel runtime linker (krtld) loads kmdb prior to the transfer of control to the kernel. If the -d flag is used, the debugger gains control of the system prior to the execution of the initial function in the 'unix' object. If -d is not used, kmdb is loaded but does not gain control until such time as it is explicitly entered. See the Debugger Entry section below. For a list of the boot commands which cause kmdb to be loaded at boot, see the SYNOPSIS section above. Boot-loaded kmdb can be unloaded only by means of a system reboot. Some features of kmdb rely on the presence of kernel services and are not immediately available to boot-loaded kmdb. In particular, the loading and unloading of dmods is not available until the module subsystem is initialized. Requests are queued until they can be processed. Similarly, translation of virtual addresses to physical addresses is not be available until the VM system has been initialized. Attempted translations fail until translation facilities are available.

kmdb can also be loaded after the system has booted, using the -K flag to mdb(1). When loaded in this fashion, it will immediately gain control of the system. Run-time-loaded kmdb can be unloaded using the -U flag to mdb(1) or from within the debugger with the -u flag to the ::quit dcmd.

When loaded, kmdb attempts to determine the proper terminal type in use on the system console. If the system being debugged has an attached keyboard and local display that are both used for the system console, kmdb uses the terminal type appropriate for the machine: 'sun' for SPARC; 'sun-color' for x86. When a serial console is in use, boot-loaded kmdb defaults to a terminal type 'vt100'. Run-time-loaded kmdb defaults to the terminal type requested by mdb(1). mdb(1) requests the terminal type specified by the value of the TERM environment variable unless overridden by the -T flag. ::term can be used to view the current terminal type.

Set a breakpoint at the specified locations. The ::bp dcmd sets a breakpoint at each address or symbol specified, including an optional address specified by an explicit expression preceding the dcmd, and each string or immediate value following the dcmd. The arguments can be symbol names or immediate values denoting a particular virtual address of interest. If a symbol name is specified, the name may refer to a symbol that cannot yet be evaluated. It might consist of an object name and function name in a load object that has not yet been opened. In such a case, the breakpoint is deferred and is not active in the target until an object matching the given name is loaded. The breakpoint is automatically enabled when the load object is opened. The -d, -D, -e, -s, -t, -T, -c, and -n options have the same meaning as they do for the ::evset dcmd. See mdb(1) for a description of ::evset. If the :b form of the dcmd is used, a breakpoint is set only at the virtual address specified by the expression preceding the dcmd. The arguments following the :b dcmd are concatenated together to form the callback string. If this string contains meta-characters, it must be quoted.

Display the last branches taken by the CPU. This dcmd is supported only on x86 systems, and is available only when processor-specific support is detected and enabled. The number and type of branches displayed is dependent on the capabilities of the branch tracing facilities provided by the CPU. When the -v option is used, the instructions prior to a given branch are displayed.

Call the specified function using the specified arguments. The called function must be listed as a function in the symbol table for a loaded module. String arguments are passed by reference. When the call completes, the return value of the function is displayed. This dcmd must be used with extreme caution. The kernel will not be resumed when the call is made. The function being called may not make any assumptions regarding the availability of any kernel services, and must not perform operations or calls that may block. The user must also beware of any side-effects introduced by the called function, as kernel stability might be affected.

Display the current general purpose register set for the specified CPU, in the format used by ::regs.

Print a C stack backtrace for the specified CPU. The backtrace displayed is for the point at which the specified CPU entered or was stopped by the debugger.

Read len bytes from the I/O port specified by addr. The value of the -L option, if provided, takes precedence over the value of the repeat count. The read length must be 1, 2, or 4 bytes, and the port address must have the same alignment as the length.

Write value to the len-byte I/O port specified by addr. The value of the -L option, if provided, takes precedence over the value of the repeat count. The write length must be 1, 2, or 4 bytes and the port address must have the same alignment as the length.

Causes the debugger to exit. When the -u option is used, the system is resumed and the debugger is unloaded. The -u option may not be used if the debugger was loaded at boot. When the -u option is not used, SPARC systems will exit to the boot PROM ok prompt. The go command can be used to re-enter the debugger. On x86 systems, a prompt is displayed that requests permission to reboot the machine.

Step the target one instruction. The optional over argument is used to step over subroutine calls. When the optional out argument is specified, the target program continues until control returns from the current function. The optional branch argument is available only on x86 systems when processor-specific support is detected and enabled. When ::step branch is specified, the target program continues until the next branching instruction is encountered. On SPARC systems, the ::step dcmd may not be used to step 'ta' instructions. Similarly, it may not be used on x86 systems to step 'int' instructions. If the step results in a trap that cannot be resolved by the debugger, a message to that effect is printed and the step will fail.

Use the specified CPU as the representative. Stack traces, general purpose register dumps, and similar functionality use the new representative CPU as the data source. Full execution control functionality is available on the new representative CPU.

Display the current terminal type.

Set a watchpoint at the specified address, interpreted by default as a virtual address. If the -p option is used, the address is interpreted as a physical address. On x86 platforms, watchpoints can be set on I/O ports using the -i option. When the -i option is used, the address is interpreted as that of an I/O port. The length in bytes of the watched region can be set by specifying an optional repeat count preceding the dcmd. If no length is explicitly set, the default is one byte. The ::wp dcmd allows the watchpoint to be configured to trigger on any combination of read (-r option), write (-w option), or execute (-x option) access. The -d, -D, -e, -s, -t, -T, -c, and -n options have the same meaning as they do for the ::evset dcmd. See mdb(1) for a description of ::evset. The :a dcmd sets a read access watchpoint at the specified address. The :p dcmd sets an execute access watchpoint at the specified address. The :w dcmd sets a write access watchpoint at the specified address. The arguments following the :a, :p, and :w dcmds are concatenated together to form the callback string. If the string contains meta-characters, it must be quoted.