threadlist is a useful macro that displays the stacks of all the threads in the system.
kadb[0]: $<threadlist ============== thread_id 10404000 p0+0x300: process args sched t0+0xa8: lwp procp wchan 1041b810 10424688 0 t0+0x24: pc sp sched+0x4f4 10403be8 ?(10404000,1040c000,2,10424604,0,6e) _start(10006ef4,1041adb0,1041adb0,1041adb0,10462910,50) + 15c ... ============== thread_id 40043e60 p0+0x300: process args sched 40043f08: lwp procp wchan 0 10424688 10473c56 40043e84: pc sp cv_wait+0x60 40043c08 ?(10473c56,10473c5c,0,40043cd0,40043e60,10093084) ufs_thread_idle(10471e80,0,10473c5c,10424688,81010100,0) + bc thread_start(0,0,0,0,0,0) + 4 ...
Another useful macro is thread. Given a thread ID, this macro prints the corresponding thread structure. This can be used to look at a certain thread found with the threadlist macro, to look at the owner of a mutex, or to look at the current thread, as shown here:
kadb[0]: <g7$<thread 70e87ac0: link stk startpc 0 4026bc80 0 70e87acc: bound_cpu affinitycnt bind_cpu 0 0 -1 70e87ad4: flag proc_flag schedflag 0 4 3 70e87ada: preempt preempt_lk state 0 0 4 70e87ae0: pri epri 40 0 70e87ae4: pc sp 10098350 4026b618 70e87aec: wchan0 wchan sobj_ops 0 0 0 70e87af8: cid clfuncs cldata 1 10470ffc 702c0488 70e87b04: ctx lofault onfault 0 0 0 ...
No type information is maintained by kadb, so using a macro on an inappropriate address results in garbage output.
Macros do not necessarily output all the fields of the structures, nor is the output necessarily in the order given in the structure definition. Occasionally, memory needs to be dumped for certain structures and then matched with the structure definition in the kernel header files.
Drivers should never reference system header files or structures not listed in man pages section 9S: DDI and DKI Data Structures. However, examining non-DDI-compliant structures (such as thread structures) can be useful in debugging drivers.