kbd -a alternate

device-specifier

Specifies the device from which to load. See monitor(1M).

As with adb(1), kernel macros can be used with kadb, but they cannot be read from a file at runtime. Use the kadb $M command to list all of the built-in kadb macros.

kadb reads commands from the standard input and displays responses on the standard output. kadb supports the majority of the adb(1) commands. kadb does not support the following adb commands: :k, :r, :i, :t, or $i. See adb(1).

Additionally, kadb supports the following commands:

[

Performs the same function as :e in adb(1), but requires only one keystroke and no RETURN (ENTER on IA based systems).

]

Performs the same function as :s in adb(1), but requires only one keystroke and no RETURN (ENTER on IA based systems).

:a

Sets a hardware access (read or write) breakpoint using the processor hardware facilities. The syntax and action for this command is the same as the :b command in adb, with the following exceptions:

• The breakpoint triggers if any bytes from the breakpoint for length bytes are being accessed. See $l below for setting the length of a hardware breakpoint.
• Breakpoints should be aligned for the length specified. Any address is valid for length 1. Addresses divisible by 2 should be used for length 2 (short). Addresses divisible by 4 should be used for length 4 (int).
• Detection of an access breakpoint occurs after completion of the instruction that caused it.
• There are a limited number (4) of hardware breakpoint registers, and, when set, this uses one.
• As this breakpoint does not modify memory locations, this command will work on locations that are not in core at the time the breakpoint is set.

@fmt

Used in the same manner as the adb / and ? commands. Specify @ as a physical memory address as opposed to the normal virtual address. Specify fmt as any of the formats used with the adb / command. This command is useful for displaying memory that may not be mapped, for example, kernel page tables or buffers used for DMA by device drivers.

function:: call arg1, arg2, arg3, ...

Invokes kernel functions with 0 or more arguments. Using this command results in a response such as:

retval = function(arg1,arg2,arg3,...);

where retval is the return value of the function. This feature can be error prone, as functions may have side effects that cause failures if the kernel is continued.

:p

Sets a hardware access (read or write) breakpoint using the processor hardware facilities when an instruction at the specified address is run. The $l operation has no effect on this type of breakpoint. This breakpoint occurs before the instruction is executed.

:P

Works as :a, but this command will only breakpoint when an access is made to the address in IA I/O space. See :a.

:w

Sets a write hardware access breakpoint using the processor hardware facilities.

[length]$l

Sets the default data length for an access or write breakpoint. length can be set to 1 for byte, 2 for short, and 4 for int word accesses. If length is not specified, 1 byte is assumed. Once set, this value affects any newly set access or write breakpoints, but does not affect ones set before this operation.

$b

Displays two additional columns that adb does not. The first is the type column which indicates soft for a normal breakpoint, access for an access hardware breakpoint, write for a write hardware breakpoint, and inst for an instruction hardware breakpoint. The second is the len column which for access and write breakpoints indicate the length of the operation to break on.

$q

Gives control to the boot prom, from which you may reboot the system.

cpu:x

Switches the active CPU to cpu. Thereafter, commands such as $r and $c displays the registers and stack of the new CPU, cpu.

port:i

Inputs a byte for display from port. port is an address-specified I/O port. For example, 330:i inputs from address port 330.

port:i8

Same as the :i command. See :i.

port:i16

Inputs two bytes for display from port. port is an address-specified I/O port.

port:i32

Inputs four bytes for display from port. port is an address-specified I/O port.

port,data:o

Outputs a byte to port. port is an address-specified I/O port. [address],[data]:o outputs the value data to address I/O port. For example, 330,80:o outputs 80 to address port 330.

port,data:o8

Same as the :o command. See port,data:o.

port,data:o16

Outputs two bytes to port. port is an address-specified I/O port.

port,data:o32

Outputs four bytes to port. port is an address-specified I/O port.

$q

Prompts the user with:

Type 'y' if you really want to reboot.

Responding with a y or Y causes the system to reboot. Responding with anything other than a y or Y returns control to kadb. Use this feature when you cannot press the reset switch on your machine. Because using $q may result in data loss, this command should only be used when you would press the reset switch or power off your system.

::help

Displays the formats of kadb commands and extended commands.

::?

Same as the ::help command. See ::help.

::morehelp

Displays additional information about commonly used commands and provides an explanation of data formats.

num::more

A common problem with using kadb is that scrolling is sometimes too fast and that CTRL-s and CTRL-q are inexact controls. A conditional scroll control feature similar to more(1) has been added to kadb. To enable this feature, the user specifies the number of lines to be displayed, followed by ::more. For example, the command 14::more displays 14 (current radix) lines, followed by the --More-- prompt. At this prompt, press: ENTER or RETURN to display one more line. Press c, C, or CTRL-c to interrupt the display. Press any other key to display the next num number of specified lines (14 in this example). The command ::more displays the current setting for the number of lines that kadb displays before printing the --More-- prompt. The initial scroll control value of this feature is 0, meaning that scrolling is disabled. Once enabled, the 0::more command disables the scroll control feature.

Since the kernel is dynamically loaded, not all modules may be loaded when a breakpoint is set kadb can set deferred breakpoints which will be dynamically inserted when the corresponding module is loaded. The module and the location must both be specified when referring to a deferred breakpoint, as follows:

module_name#location:

This syntax is implemented for kadb only and uses existing breakpoint commands (for example, ufs#ufs_open:b or ufs#ufs_open+4,5:b).

If the module has been loaded, kadb attempts to find the symbol in the module specified. If kadb finds the symbol, it sets a regular breakpoint. If it does not find the symbol, it generates an error message and returns to the command line without setting a breakpoint.

If kadb fails to find the module on the list of currently loaded modules, it does not resolve the location. Instead, it sends a message to the user and sets a deferred breakpoint.

When the specified module is loaded, kadb tries to resolve the location. If the location can be resolved, the deferred breakpoint is converted to a regular breakpoint. If kadb cannot resolve the location, a message is sent to the user, and kadb halts execution. In this case, kadb does not convert the deferred breakpoint to a regular breakpoint; it removes it from the breakpoint table. The user may then re-enter a correct breakpoint. Strict scoping is enforced, so kadb does not look at any other module than the one specified with the location.

When specifying a deferred breakpoint in which the module name contains a hyphen, you must escape the hyphen. For example, for a module named pci-ide, enter:

pci\-ide#_init:b

The output from the the $b command indicates whether the breakpoint is of type "deferred" (defr) or is another type.

kbd(1), monitor(1M), obpsym(1M)

On a SPARC based system, kadb cannot reliably single-step over instructions which change the processor status register.

If a breakpoint or watchpoint is triggered while the console frame buffer is powered off, the system can crash and be left in a state from which it is difficult to recover. If one of these is triggered while the monitor is powered off, you will not be able to see the debugger output.