Unlike adb, kadb runs in the same supervisor virtual address space as the program being debugged -- although it maintains a separate context. The debugger runs as a coprocess that cannot be killed (no `:k') or rerun (no `:r'). There is no signal control (no `:i', `:t', or `$i'), although the keyboard facilities (CTRL-C, CTRL-S, and CTRL-Q) are simulated.
While the kernel is running under kadb, the abort sequence (L1-A or BREAK) drops the system into kadb for debugging -- as will a system panic. When running other standalone programs under kadb, the abort sequence will pass control to the PROM monitor. kadb is then invoked from the monitor by jumping to the starting address for kadb found in /usr/include/debug/debug.h The following list gives the monitor commands to use for each system.
System Monitor Command Sun-2 g fd00000 Sun-3 g fd00000 Sun386i g fe005000 Sun-4 g ffc00000 Sun-4c go ffc00000 Sun-4m go ffc00000
The kadb user interface is similar to that of adb. Note: kadb prompts with
kadb>
Most adb commands function in kadb as expected. Typing an abort sequence in response to the prompt (use $q on Sun-4m ) returns you to the PROM monitor, from which you can examine control spaces that are not accessible within adb or kadb. The PROM monitor command c (or go on Sun-4c/4m) will return control to kadb. As with `adb -k', $p works when debugging kernels (by actually mapping in new user pages). The verbs ? and / are equivalent in kadb , since there is only one address space in use.
kadb is booted from the PROM monitor as a standalone program. If you omit the -d flag, kadb automatically loads and runs vmunix from the filesystem kadb was loaded from. The kadb vmunix variable can be patched to change the default program to be loaded.
for a file to be loaded. From here, you can enter a boot sequence line to load a standalone program. Boot flags entered in response to this prompt are included with those already set and passed to the program. If you type a RETURN only, kadb loads vmunix from the filesystem that kadb was loaded from.
As with adb, kernel macros are supported. With kadb, however, the macros are compiled into the debugger itself, rather than being read in from the filesystem. The kadb command $M lists macros known to kadb.
Self-relocating programs such as the SunOS kernel need to be relocated before breakpoints can be used. To set the first breakpoint for such a program, start it with `:s'; kadb is then entered after the program is relocated (when the system initializes its interrupt vectors). Thereafter, `:s' single-steps as with adb. Otherwise, use `:c' to start up the program.
The Sun386i system version of kadb has the following additional commands. Note, for the general syntax of adb commands, see adb.1
You can set up your workstation to automatically reboot kadb by patching the vmunix variable in /boot with the string kadb. (Refer to adb in [a manual with the abbreviation DEBUG] for details on how to patch executables.)
[a manual with the abbreviation DEBUG]
[a manual with the abbreviation DRIVER]
There is no floating-point support, except on Sun386i systems.
kadb cannot reliably single-step over instructions that change the status register.
When sharing the keyboard with the operating system the monitor's input routines can leave the keyboard in a confused state. If this should happen, disconnect the keyboard momentarily and then reconnect it. This forces the keyboard to reset as well as initiating an abort sequence.
Most of the bugs listed in adb.1 also apply to kadb.
Created by unroff & hp-tools. © somebody (See intro for details). All Rights Reserved. Last modified 11/5/97