DDB(4)

📦 version 12.2, in debian bookworm, debian trixie, ubuntu jammy, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

DDB(4) — Kernel Interfaces Manual 💖

okay bestie, sit down, hydrate, because we're about to talk about ddb — the interactive kernel debugger ✨ and honestly? she's iconic.

✨ NAME ✨

ddb — interactive kernel debugger 💅

🌸 SYNOPSIS 🌸

ok so, first things first: to enable kernel debugging facilities, you include:

options KDB
options DDB

and if you want to prevent activation of the debugger on panic(9):

options KDB_UNATTENDED

and if you want a stack trace of the current thread on the console for a panic, add:

options KDB_TRACE

want the numerical value of symbols in addition to the symbolic representation? then define:

options DDB_NUMSYM

and if you want the gdb(1) backend enabled so that remote debugging with kgdb(1) is possible, include:

options GDB

🫶 that's the whole menu, no cap.

🦋 DESCRIPTION 🦋

the ddb kernel debugger is an interactive debugger with a syntax inspired by gdb(1). if she's linked into the running kernel, you can invoke her locally with the ‘debug’ keymap(5) action. she also gets invoked on panic(9) if the debug.debugger_on_panic sysctl(8) MIB variable is set non-zero — and that's the default, unless you specified the KDB_UNATTENDED option. (yes bestie, she shows up to the party uninvited by default. main character energy.)

the current location is called dot ⭐. dot is displayed with a hexadecimal format at a prompt. the commands examine and write update dot to the address of the last line examined or the last location modified, and set next to the address of the next location to be examined or changed. other commands do not change dot, and set next to be the same as dot.

the general command syntax is:

command[/modifier] [addr][,count]

a blank line repeats the previous command from the address next with count 1 and no modifiers. specifying addr sets dot to the address. omitting addr uses dot. a missing count is taken to be 1 for printing commands, or infinity for stack traces 🌈. a count of -1 is equivalent to a missing count. options that are supplied but not supported by the given command are usually ignored (she's chill like that).

also! ddb has a pager feature (like the more(1) command) for the output. if an output line exceeds the number set in the lines variable, she displays “--More--” and waits for a response. the valid responses for it are:

  • SPC — one more page
  • RET — one more line
  • q — abort the current command, and return to the command input mode

and finally, ddb provides a small (currently 10 items) command history, plus simple emacs-style command line editing capabilities 💜. in addition to the emacs control keys, the usual ANSI arrow keys may be used to browse through the history buffer, and move the cursor within the current line. obsessed.

👑 COMMANDS 👑

🔍 examine

examine[/AISabcdghilmorsuxz ...] [addr][,count]
x[/AISabcdghilmorsuxz ...] [addr][,count]

display the addressed locations according to the formats in the modifier. multiple modifier formats display multiple locations. if no format is specified, the last format specified for this command is used.

the format characters are:

  • b — look at by bytes (8 bits)
  • h — look at by half words (16 bits)
  • l — look at by long words (32 bits)
  • g — look at by quad words (64 bits)
  • a — print the location being displayed
  • A — print the location with a line number if possible
  • x — display in unsigned hex
  • z — display in signed hex
  • o — display in unsigned octal
  • d — display in signed decimal
  • u — display in unsigned decimal
  • r — display in current radix, signed
  • c — display low 8 bits as a character. non-printing characters are displayed as an octal escape code (e.g., ‘\000’)
  • s — display the null-terminated string at the location. non-printing characters are displayed as octal escapes
  • m — display in unsigned hex with character dump at the end of each line. the location is also displayed in hex at the beginning of each line
  • i — display as an instruction
  • I — display as an instruction with possible alternate formats depending on the machine. on i386, this selects the alternate format for the instruction decoding (16 bits in a 32-bit code segment and vice versa)
  • S — display a symbol name for the pointer stored at the address

⏩ xf

Examine forward: execute an examine command with the last specified parameters to it, except that the next address displayed by it is used as the start address. slay.

⏪ xb

Examine backward: execute an examine command with the last specified parameters to it, except that the last start address subtracted by the size displayed by it is used as the start address.

🖨️ print

print[/acdoruxz]
p[/acdoruxz]

print addrs according to the modifier character (as described above for examine). valid formats are: a, x, z, o, d, u, r, and c. if no modifier is specified, the last one specified to it is used. the argument addr can be a string, in which case it is printed as it is. for example:

print/x "eax = " $eax "\necx = " $ecx "\n"

will print like:

eax = xxxxxx
ecx = yyyyyy

periodt 💅

✍️ write

write[/bhl] addr expr1 [expr2 ...]
w[/bhl] addr expr1 [expr2 ...]

write the expressions specified after addr on the command line at succeeding locations starting with addr. the write unit size can be specified in the modifier with a letter b (byte), h (half word) or l (long word) respectively. if omitted, long word is assumed.

⚠️ Warning: since there is no delimiter between expressions, strange things may happen 😭. it is best to enclose each expression in parentheses. fr fr, do it.

🎀 set

set $variable [=] expr

set the named variable or register with the value of expr. valid variable names are described below. (iykyk)

🛑 break

break[/u] [addr][,count]
b[/u] [addr][,count]

set a break point at addr. if count is supplied, the continue command will not stop at this break point on the first count - 1 times that it is hit. if the break point is set, a break point number is printed with ‘#’. this number can be used in deleting the break point or adding conditions to it.

if the u modifier is specified, this command sets a break point in user address space. without the u option, the address is considered to be in the kernel space, and a wrong space address is rejected with an error message. this modifier can be used only if it is supported by machine dependent routines.

⚠️ Warning: if a user text is shadowed by a normal user space debugger, user space break points may not work correctly. setting a break point at the low-level code paths may also cause strange behavior. 💀

🗑️ delete

delete [addr]
d [addr]
delete #number
d #number

delete the specified break point. the break point can be specified by a break point number with ‘#’, or by using the same addr specified in the original break command, or by omitting addr to get the default address of dot.

👀 watch

watch [addr][,size]

set a watchpoint for a region. execution stops when an attempt to modify the region occurs. the size argument defaults to 4. if you specify a wrong space address, the request is rejected with an error message.

⚠️ Warning: attempts to watch wired kernel memory may cause unrecoverable error in some systems such as i386. watchpoints on user addresses work best. 🌸

🔧 hwatch

hwatch [addr][,size]

set a hardware watchpoint for a region if supported by the architecture. execution stops when an attempt to modify the region occurs. the size argument defaults to 4.

⚠️ Warning: the hardware debug facilities do not have a concept of separate address spaces like the watch command does. use hwatch for setting watchpoints on kernel address locations only, and avoid its use on user mode address spaces. no cap.

🚮 dhwatch

dhwatch [addr][,size]

delete specified hardware watchpoint.

👟 step

step[/p][,count]
s[/p][,count]

single step count times. if the p modifier is specified, print each instruction at each step. otherwise, only print the last instruction.

⚠️ Warning: depending on machine type, it may not be possible to single-step through some low-level code paths or user space code. on machines with software-emulated single-stepping (e.g., pmax), stepping through code executed by interrupt handlers will probably do the wrong thing. 😭

▶️ continue

continue[/c]
c[/c]

continue execution until a breakpoint or watchpoint. if the c modifier is specified, count instructions while executing. some machines (e.g., pmax) also count loads and stores.

⚠️ Warning: when counting, the debugger is really silently single-stepping. this means that single-stepping on low-level code may cause strange behavior. 💀

🛬 until

until[/p]

stop at the next call or return instruction. if the p modifier is specified, print the call nesting depth and the cumulative instruction count at each call or return. otherwise, only print when the matching return is hit.

⏭️ next

next[/p]
match[/p]

stop at the matching return instruction. if the p modifier is specified, print the call nesting depth and the cumulative instruction count at each call or return. otherwise, only print when the matching return is hit.

🧵 trace

trace[/u] [pid | tid][,count]
t[/u] [pid | tid][,count]
where[/u] [pid | tid][,count]
bt[/u] [pid | tid][,count]

Stack trace 🌈. the u option traces user space; if omitted, trace only traces kernel space. the optional argument count is the number of frames to be traced. if count is omitted, all frames are printed.

⚠️ Warning: user space stack trace is valid only if the machine dependent code supports it.
search[/bhl] addr value [mask][,count]

search memory for value. the optional count argument limits the search.

🪺 findstack

findstack addr

prints the thread address for a thread kernel-mode stack of which contains the specified address. if the thread is not found, search the thread stack cache and prints the cached stack address. otherwise, prints nothing.

okay bestie that's part 1 💖 keep reading, there's more where that came from ✨

  • show all procs[/a] / ps[/a] — the full process info dump 💖 it displays all process information. lowkey there's a catch tho: the process information may not be shown if it isn't supported in the machine, or if the bottom of the stack of the target process isn't in main memory at that time 🙈. add the a modifier and it also prints the command line arguments for each process ✨
  • show all trace / alltrace — shows a stack trace for every thread in the system 🌈 like, the whole entire system. no cap.
  • show all ttys — shows all the TTY's within the system 🎀 the output is similar to pstat(8), but it also throws in the address of the TTY structure. slay.
  • show all vnets — gives you the exact same output as "show vnet" does, except it lists all the virtualized network stacks within the system 🦋
  • show allchains — shows the same information as "show lockchain" does, but for every thread in the system 💅
  • show alllocks — shows all locks that are currently held 👑 > heads up bestie: this command is only available if witness(4) is included in the kernel.
  • show allpcpu — the same as "show pcpu", but for every CPU present in the system 🔥
  • show allrman — shows information related with resource management, including interrupt request lines, DMA request lines, I/O ports, I/O memory addresses, and Resource IDs 💜
  • show apic — dumps data about APIC IDT vector mappings ✨
  • show breaks — shows the breakpoints you set with the "break" command 🎀
  • show bio addr — shows information about the bio structure struct bio present at addr. peep the sys/bio.h header file and g_bio(9) for more details on the exact meaning of the structure fields 🌸
  • show buffer addr — shows information about the buf structure struct buf present at addr. see the sys/buf.h header file for more details on the exact meaning of the structure fields 🦋
  • show callout addr — shows information about the callout structure struct callout present at addr ⭐
  • show cbstat — shows brief information about the TTY subsystem 💅
  • show cdev — with no argument, it shows the list of all created cdev's, consisting of the devfs node name and struct cdev address 👀. when an address of cdev is supplied, it shows some internal devfs state of the cdev ✨
  • show conifhk — lists hooks currently waiting for completion in run_interrupt_driven_config_hooks() 🎀
  • show cpusets — prints numbered root and assigned CPU affinity sets. see cpuset(2) for more details 💜
  • show cyrixreg — shows registers specific to the Cyrix processor 🧚
  • show devmap — prints the contents of the static device mapping table. currently only available on the ARM architecture 💀
  • show domain addr — prints the protocol domain structure struct domain at address addr. see the sys/domain.h header file for more details on the exact meaning of the structure fields 🌈
  • show ffs [addr] — shows brief information about the ffs mount at the address addr, if that argument is given. otherwise, it provides the summary about each ffs mount 🌸
  • show file addr — shows information about the file structure struct file present at address addr ✨
  • show files — shows information about every file structure in the system 👑
  • show freepages — shows the number of physical pages in each of the free lists 🎀
  • show geom [addr] — if the addr argument is not given, it displays the entire GEOM topology 🦋. if addr is given, it displays details about the given GEOM object (class, geom, provider or consumer) 💅
  • show idt — shows the IDT layout. the first column specifies the IDT vector. the second one is the name of the interrupt/trap handler. those functions are machine dependent 🧚
  • show igi_list addr — shows information about the IGMP structure struct igmp_ifsoftc present at addr 💜
  • show inodedeps [addr] — shows brief information about each inodedep structure. if addr is given, only inodedeps belonging to the fs located at the supplied address are shown 👀
  • show inpcb addr — shows information on the IP Control Block struct in_pcb present at addr 🌸
  • show intr — dumps information about interrupt handlers ✨
  • show intrcnt — dumps the interrupt statistics 🔥
  • show irqs — shows interrupt lines and their respective kernel threads 🎀
  • show jails — shows the list of jail(8) instances. on top of what jls(8) shows, it also lists kernel internal details 👑
  • show lapic — shows information from the local APIC registers for this CPU 💅
  • show lock addr — shows the lock structure. the output format goes like this:
    • class: — class of the lock. possible types include mutex(9), rmlock(9), rwlock(9), sx(9).
    • name: — name of the lock.
    • flags: — flags passed to the lock initialization function. flags values are lock class specific.
    • state: — current state of a lock. state values are lock class specific.
    • owner: — lock owner.
  • show lockchain addr — shows all threads a particular thread at address addr is waiting on, based on non-spin locks 🦋
  • show lockedbufs — shows the same information as "show buf", but for every locked struct buf object 🎀
  • show lockedvnods — lists all locked vnodes in the system 🌈
  • show locks — prints all locks that are currently acquired. > bestie this one is only available if witness(4) is included in the kernel 💖
  • show locktree — ok she's listed here with literally no description attached, so... mysterious icon energy 👀✨
  • show malloc — prints malloc(9) memory allocator statistics. the output format goes like this:
    • Type — specifies a type of memory. it's the same as the description string used while defining the given memory type with MALLOC_DECLARE(9).
    • InUse — number of memory allocations of the given type, for which free(9) has not been called yet.
    • MemUse — total memory consumed by the given allocation type.
    • Requests — number of memory allocation requests for the given memory type.

the same information can be gathered in userspace with "vmstat -m" 💅

  • show map[/f] addr — prints the VM map at addr. if the f modifier is specified, the complete map is printed 🎀
  • show msgbuf — prints the system's message buffer. it's the same output as in the "dmesg" case 🌸. it's useful if you got a kernel panic, attached a serial cable to the machine, and want to get the boot messages from before the system hang 😭🫶
  • show mount — displays short info about all currently mounted file systems 🦋
  • show mount addr — displays details about the given mount point ✨
  • show object[/f] addr — prints the VM object at addr. if the f option is specified, the complete object is printed 💜
  • show panic — prints the panic message if it's set 💀
  • show page — shows statistics on VM pages 🎀
  • show pageq — shows statistics on VM page queues ⭐
  • show pciregs — prints PCI bus registers. the same information can be gathered in userspace by running "pciconf -lv" 🔥
  • show pcpu — prints the current processor state. the output format goes like this:
    • cpuid — processor identifier.
    • curthread — thread pointer, process identifier and the name of the process.
    • curpcb — control block pointer.
    • fpcurthread — FPU thread pointer.
    • idlethread — idle thread pointer.
    • APIC ID — CPU identifier coming from APIC.
    • currentldt — LDT pointer.
    • spin locks held — names of spin locks held.
  • show pgrpdump — dumps process groups present within the system 👑
  • show proc [addr] — if no [addr] is specified, it prints information about the current process. otherwise, it shows information about the process at address addr 💅
  • show procvm — shows the process virtual memory layout 🌈
  • show protosw addr — prints the protocol switch structure struct protosw at address addr 🦋
  • show registers[/u] — displays the register set. if the u modifier is specified, it displays user registers instead of kernel registers, or the currently saved one 👀
Warning: the support of the u modifier depends on the machine. if it's not supported, incorrect information will be displayed 💀
  • show rman addr — shows the resource manager object struct rman at address addr. addresses of particular pointers can be gathered with the "show allrman" command 🎀
  • show rtc — shows the real time clock value. useful for long debugging sessions ⏰✨
  • show sleepchain — deprecated 🫠 it's now an alias for show lockchain.
  • show sleepq / show sleepqueue — both commands provide the exact same functionality 💅 they show the sleepqueue struct sleepqueue structure. sleepqueues are used within the FreeBSD kernel to implement sleepable synchronization primitives (thread holding a lock might sleep or be context switched), which at the time of writing are: condvar(9), sx(9) and the standard msleep(9) interface 🌸
  • show sockbuf addr / show socket addr — those commands print struct sockbuf and struct socket objects placed at addr. the output consists of all values present in the structures mentioned. for exact interpretation and more details, visit the sys/socket.h header file 🦋
  • show sysregs — shows system registers (e.g., cr0-4 on i386.) not present on some platforms 🙈
  • show tcpcb addr — prints the TCP control block struct tcpcb lying at address addr. for exact interpretation of the output, visit the netinet/tcp.h header file 💜
  • show thread [addr] — if no addr is specified, it shows detailed information about the current thread. otherwise, information about the thread at addr is printed ✨
  • show threads — shows all threads within the system 👑 the output format goes like this:
    • First column — thread identifier (TID)
    • Second column — thread structure address
    • Third column — backtrace.
  • show tty addr — drops the contents of a TTY structure, but in a readable form so your eyes don't bleed 💖
  • show turnstile addr — shows the struct turnstile structure living at address addr. Turnstiles are these little structures inside the FreeBSD kernel that implement synchronization primitives which, while holding a specific type of lock, cannot sleep or context switch to another thread. RN the ones in question are: mutex(9), rwlock(9), rmlock(9).
  • show uma — shows UMA allocator statistics. The output is five columns, bestie, count 'em:
    • Zone — name of the UMA zone. Same string that got passed to uma_zcreate(9) as the first argument.
    • Size — size of a given memory object (slab).
    • Used — number of slabs currently being used.
    • Free — number of free slabs within the UMA zone.
    • Requests — number of allocation requests to the given zone.

iykyk: the exact same info can be gathered in userspace with a lil help from vmstat -z.

  • show unpcb addr — shows the UNIX domain socket private control block struct unpcb that's present at the address addr.
  • show vmochk — prints whether the internal VM objects are in a map somewhere, and whether none of them have zero ref counts.
  • show vmopag — this is supposed to show the physical addresses consumed by a VM object. Currently it is not possible to use this command when witness(4) is compiled in the kernel 😭 so like. keep that in mind.
  • show vnet addr — prints the virtualized network stack struct vnet structure present at the address addr.
  • show vnode [addr] — prints the struct vnode structure lying at [addr]. For the exact interpretation of the output, go look at the sys/vnode.h header file, no cap.
  • show vnodebufs addr — shows the clean/dirty buffer lists of the vnode located at addr.
  • show vpath addr — walks the namecache to look up the pathname of the vnode located at addr.
  • show watches — displays all watchpoints. Basically shows the watchpoints you set with the "watch" command 👀
  • show witness — shows info about lock acquisition coming from the witness(4) subsystem.
  • gdb — toggles between remote GDB and DDB mode. In remote GDB mode you need another machine running gdb(1) using the remote debug feature, connected to the serial console port on the target machine. Currently only available on the i386 architecture.
  • halt — halts the system. that's it, that's the whole thing 💀
  • kill sig pid — sends signal sig to process pid. The signal gets acted on upon returning from the debugger. This one's your girl when you gotta kill a process causing resource contention in the case of a hung system. See signal(3) for a list of signals. Note that the arguments are reversed relative to kill(2) — do not get caught slipping.
  • reboot [seconds]
  • reset [seconds] — hard reset the system. If the optional argument seconds is given, the debugger will wait for this long — at most a week — before rebooting.
  • help — prints a short summary of the available commands and command abbreviations. the little cheat sheet, we love her 🫶
  • capture on
  • capture off
  • capture reset
  • capture status — ddb supports a basic output capture facility, and it can be used to retrieve the results of debugging commands from userspace using sysctl(3). capture on enables output capture; capture off disables it. capture reset clears the capture buffer and disables capture. capture status reports current buffer use, buffer size, and disposition of output capture.

Userspace processes may inspect and manage ddb capture state using sysctl(8):

  • debug.ddb.capture.bufsize — query or set the current capture buffer size.
  • debug.ddb.capture.maxbufsize — query the compile-time limit on the capture buffer size.
  • debug.ddb.capture.bytes — query the number of bytes of output currently in the capture buffer.
  • debug.ddb.capture.data — returns the contents of the buffer as a string to an appropriately privileged process.

This facility is especially useful in concert with the scripting and textdump(4) facilities, letting scripted debugging output get captured and committed to disk as part of a textdump for later analysis. The contents of the capture buffer may also be inspected in a kernel core dump using kgdb(1) ✨

  • run
  • script
  • scripts
  • unscript — run, define, list, and delete scripts. See the "SCRIPTING" section for more on the scripting facility.
  • textdump dump
  • textdump set
  • textdump status
  • textdump unset — use the textdump dump command to immediately perform a textdump. More info lives in textdump(4). The textdump set command may be used to force the next kernel core dump to be a textdump rather than a traditional memory dump or minidump. textdump status reports whether a textdump has been scheduled. textdump unset cancels a request to perform a textdump as the next kernel core dump.

✨ VARIABLES ✨

The debugger accesses registers and variables as $name. Register names are as in the "show registers" command. Some variables are suffixed with numbers, and they may have some modifier following a colon immediately after the variable name. For example, register variables can have a u modifier to indicate user register (e.g., "$eax:u").

Built-in variables currently supported are:

  • radix — input and output radix.
  • maxoff — addresses are printed as "symbol+offset" unless offset is greater than maxoff.
  • maxwidth — the width of the displayed line.
  • lines — the number of lines. It's used by the built-in pager. Setting it to 0 disables paging.
  • tabstops — tab stop width.
  • workxx — work variable; xx can take values from 0 to 31.

💅 EXPRESSIONS 💅

Most expression operators in C are supported — except '~', '^', and unary '&'. The special rules in ddb are:

  • Identifiers — the name of a symbol is translated to the value of the symbol, which is the address of the corresponding object. '.' and ':' can be used in the identifier. If supported by an object format dependent routine, [filename:]func:lineno, [filename:]variable, and [filename:]lineno can be accepted as a symbol.
  • Numbers — radix is determined by the first two letters: '0x': hex, '0o': octal, '0t': decimal; otherwise, follow the current radix.
  • . — dot
  • + — next
  • .. — address of the start of the last line examined. Unlike dot or next, this is only changed by the examine or write command.
  • ' — last address explicitly specified.
  • $variable — translated to the value of the specified variable. It may be followed by a ':' and modifiers as described above.
  • a#b — a binary operator which rounds up the left hand side to the next multiple of the right hand side.
  • *expr — indirection. It may be followed by a ':' and modifiers as described above.

📜 SCRIPTING 💅

okay bestie, this is the part where ddb gets ambitious. it has a whole little scripting facility so you can automate tasks or set up responses to specific events, no cap. each script is just a list of DDB commands that run one after another in order, and it gets its own unique name. some names are special — if you define a script with one of those names, it'll run automatically when the matching ddb event happens. iconic behavior honestly.

the script command is how you define a script by name. scripts are a bunch of ddb commands separated with the ; character. like, for example:

script kdb.enter.panic=bt; show pcpu
script lockinfo=show alllocks; show lockedvnods

the scripts command lists all the scripts you've defined so far. 🎀

the run command executes a script by name. for example:

run lockinfo

and the unscript command deletes a script by name, rip to that script. for example:

unscript kdb.enter.panic

fun fact: you can also do all of these things from userspace using the ddb(8) command. versatility ✨

🦋 the automatic scripts (the ones that run themselves)

certain scripts get run automatically if they're defined, for specific ddb events. here are all the scripts that fire when stuff happens:

  • kdb.enter.acpi — the kernel debugger got entered because of an acpi(4) event.
  • kdb.enter.bootflags — the kernel debugger got entered at boot because the debugger boot flag was set.
  • kdb.enter.break — the kernel debugger got entered because of a serial or console break.
  • kdb.enter.cam — the kernel debugger got entered because of a CAM(4) event.
  • kdb.enter.mac — the kernel debugger got entered because of an assertion failure in the mac_test(4) module of the TrustedBSD MAC Framework.
  • kdb.enter.ndis — the kernel debugger got entered because of an ndis(4) breakpoint event.
  • kdb.enter.netgraph — the kernel debugger got entered because of a netgraph(4) event.
  • kdb.enter.panic — panic(9) was called.
  • kdb.enter.powerfail — the kernel debugger got entered because of a powerfail NMI on the sparc64 platform.
  • kdb.enter.powerpc — the kernel debugger got entered because of an unimplemented interrupt type on the powerpc platform.
  • kdb.enter.sysctl — the kernel debugger got entered because the debug.kdb.enter sysctl was set.
  • kdb.enter.trapsig — the kernel debugger got entered because of a trapsig event on the sparc64 platform.
  • kdb.enter.unionfs — the kernel debugger got entered because of an assertion failure in the union file system.
  • kdb.enter.unknown — the kernel debugger got entered, but no reason has been set. mysterious. 🙈
  • kdb.enter.vfslock — the kernel debugger got entered because of a VFS lock violation.
  • kdb.enter.watchdog — the kernel debugger got entered because of a watchdog firing.
  • kdb.enter.witness — the kernel debugger got entered because of a witness(4) violation.

and if none of those scripts exist? ddb will try to execute a default script:

  • kdb.enter.default — the kernel debugger got entered, but no script exactly matching the reason for entering was defined. this is your catch-all for cases you don't specifically care about. for example, kdb.enter.witness could be defined to have special handling, and kdb.enter.default could just panic and reboot. the "idk just reboot" strategy, honestly relatable 💀

💡 HINTS ✨

on machines with an ISA expansion bus, you can literally build a simple NMI generation card by connecting a push button between the A01 and B01 (CHCHK# and GND) card fingers. momentarily shorting those two fingers together may cause the bridge chipset to generate an NMI, which makes the kernel hand control over to ddb. but some bridge chipsets don't generate a NMI on CHCHK#, so your mileage may vary. 🙃

the NMI lets you break into the debugger on a wedged machine so you can diagnose problems — like a little rescue mission. other bus' bridge chipsets may be able to generate NMI using bus specific methods. there are lots of PCI and PCIe add-in cards that can generate NMI for debugging. modern server systems typically use IPMI to generate signals to enter the debugger, and the devel/ipmitool port can send the chassis power diag command, which delivers an NMI to the processor. embedded systems often use JTAG for debugging, but rarely use it in combination with ddb.

for serial consoles, you can enter the debugger by sending a BREAK condition on the serial line — but only if options BREAK_TO_DEBUGGER is specified in the kernel. most terminal emulation programs can send a break sequence with a special key sequence or via a menu item. however, in some setups sending the break can be difficult to arrange or happens spuriously, so if the kernel contains options ALT_BREAK_TO_DEBUGGER then:

  • the sequence of CR TILDE CTRL-B enters the debugger 🫶
  • CR TILDE CTRL-P causes a panic instead of entering the debugger 😭
  • CR TILDE CTRL-R causes an immediate reboot 🔥

in all the above sequences, CR is a Carriage Return and is usually sent by hitting the Enter or Return key. TILDE is the ASCII tilde character (~). CTRL-x is Control x, created by hitting the control key and then x and then releasing both.

okay so lowkey important: the break-to-enter-the-debugger behavior can be enabled at run-time by setting the sysctl(8) debug.kdb.break_to_debugger to 1. the alternate sequence to enter the debugger behavior can be enabled at run-time by setting the sysctl(8) debug.kdb.alt_break_to_debugger to 1. and the debugger can be entered by setting the sysctl(8) debug.kdb.enter to 1. three little sysctls, three big vibes.

📂 FILES

header files mentioned in this manual page can be found below the /usr/include directory:

  • sys/buf.h
  • sys/domain.h
  • netinet/in_pcb.h
  • sys/socket.h
  • sys/vnode.h

👀 SEE ALSO

gdb(1), kgdb(1), acpi(4), CAM(4), mac_test(4), ndis(4), netgraph(4), textdump(4), witness(4), ddb(8), sysctl(8), panic(9)

like, go read those too, they're the extended universe bestie 💜

📖 HISTORY

the ddb debugger was developed for Mach, and ported to 386BSD 0.1. this manual page was translated from man(7) macros by Garrett Wollman.

Robert N. M. Watson added support for ddb output capture, textdump(4) and scripting in FreeBSD 7.1. king behavior, honestly 👑

and that's the whole page bestie!! this edition is the Debian one, dated September 7, 2018 — go forth and debug slayfully, DDB(4) out 💅✨

📦 where this page comes from