MDB provides facilities to examine the stacks and registers of each thread associated with the target. The persistent thread variable contains the current representative thread identifier. The format of the thread identifier depends on the target. The ::regs and ::fpregs dcmds can be used to examine the register set of the representative thread, or of another thread if its register set is currently available. In addition, the register set of the representative thread is exported as a set of named variables. The user can modify the value of one or more registers by applying the '>' dcmd to the corresponding named variable.
The MDB kernel target exports the virtual address of the corresponding internal thread structure as the identifier for a given thread. This address corresponds to the kthread_t data structure in the operating system source code. When using kmdb, the CPU identifier for the CPU running kmdb is stored in the cpuid variable.
The MDB process target provides proper support for examination of multi-threaded user processes that use the native lwp_* interfaces, /usr/lib/libthread.so, or /usr/lib/libpthread.so. When debugging a live user process, MDB will detect if a single threaded process dlopens or closes libthread and will automatically adjust its view of the threading model on-the-fly. The process target thread identifiers will correspond to either the lwpid_t, thread_t, or pthread_t of the representative, depending on the threading model used by the application.
If MDB is debugging a user process target and the target makes use of compiler-supported thread-local storage, MDB will automatically evaluate symbol names referring to thread-local storage to the address of the storage corresponding to the current representative thread. The ::tls built-in dcmd can be used to display the value of the symbol for threads other than the representative thread.
kmdb provides the thread spin functionality to debug and reproduce the race or hang conditions where the race window is very narrow. The thread spin functionality allows kmdb to instruct the threads to go into a spin state at a desired point. kmdb supports the following spin functions:
::spin arm – Extend the continue state of the software event in a thread lifecycle. Multiple threads can be in the spin state simultaneously. Use ::spin resume to resume thread execution.
::spin resume – Resume execution of the thread that was in the spin state. Invoke this command manually.
::spin list – List all threads that are in the spin state. In contrast, ::events displays only software events and their states.