Re: cvs commit: src/sys/bus/usb usb_ethersubr.c src/sys/kern kern_poll.c uipc_msg.c src/sys/net netisr.c netisr.h src/sys/net/ppp if_ppp.c src/sys/netgraph/netgraph ng_base.c src/sys/netinet if_ether.c ip_demux.c ip_input.c tcp_subr.c ...

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:>     Yes, you should be able to specify the pid:
:> 
:>     gdb> proc 27
:>     gdb> back
:
:I tried this, but gdb says `invalid proc address' for any existing pids,
:and `invalid pid' for non-existent process. Specifying thread structure
:address always seems to work though.

    Shoot, I thought I fixed that.  Make sure your gdb is contemporary
    with your kernel (e.g. recently built).  An old kernel (over a 3 weeks
    or so old) and a new gdb, or a new kernel and an old gdb may not be
    able to lookup the PID.  Unfortunately, gdb needs to have knowledge
    of struct proc, struct thread, and a few other kernel structures to
    track down the pid.
 
:>     For pure threads, supply the address of the thread structure.
:> 
:>     gdb> proc 0x<address_of_thread_structure>
:>     gdb> back
:> 
:>     Here is a handy GDB macro procedure to generate a 'ps', put it in
:>     your ~/.gdbinit file.
:> 
:[gdb script]
:
:Thanks, this works for me.

    Ok, that's good.  Our GDB has a lot of hacks in it to deal with 
    threads and thread contexts properly.  For example, if a thread is
    the 'current' thread on a cpu we have to pull the context out of state
    that DDB saves when it was entered.  If the thread is not current and
    has no process we have to pull the stack pointer from the thread structure,
    and if the thread is not current and has a process the context is stored
    in the PCB and we have to get the stack pointer from that. 

    It's a real mess but I think worth it in the end because always having
    to synchronize the register state to the PCB (instead of just pushing 
    a partial register state on the kernel stack) adds a huge amount of
    overhead to the thread switch code.  Even FreeBSD had to make a distinction
    between 'current' processes (ddb saved state) and non-current processes
    (pcb saved state).

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>