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