Tracing different threads in DDB
Matthew Dillon
dillon at apollo.backplane.com
Sat Nov 15 10:22:31 PST 2003
:How do I get the trace of another thread's stack in DDB? When breaking
:to the debugger from the console, the trace defaults to the interrupt
:handler that serviced the break. The DDB man page says that trace takes
:the stack frame as an argument. Should I just use the thread address
:given in ps?
:
:Also, am I reading the output of ps correctly? The first block is a
:listing of anything with a process context. The second block is a listing
:of threads servicing system calls for the above processes and the last
:block lists all of the system threads?
:
:--
: David P. Reese, Jr. daver at xxxxxxxxxxxx
: http://www.gomerbud.com/daver/
The first block is the user process scheduler list, which means
all threads with process contexts. Then for each cpu in the system
there are two additional blocks: One showing the LWKT scheduler's
run queue, then the LWKT scheduler's all-threads queue.
You can trace any process's stack by just specifying PID, e.g.
'trace 1'.
Tracing pure threads is harder because I haven't hooked in the
frame, but if you have a stack pointer you can try tracing based
on the stack pointer. e.g. 'trace 0xc0134520'. It may or may not
work.
-Matt
Matthew Dillon
<dillon at xxxxxxxxxxxxx>
More information about the Kernel
mailing list