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 at apollo.backplane.com
Wed Apr 14 09:57:39 PDT 2004
:> 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 at xxxxxxxxxxxxx>
More information about the Commits
mailing list