:Here's what pstack does:
:
: pstack Print a hex+symbolic stack trace for each lwp in
: each process.
:
:Solaris truss(1) has this:
:
: -l Includes the id of the responsible lightweight
: process (LWP) with each line of trace output. If
: -f is also specified, both the process-id and the
: LWP-id are included.
:
:Justin says:
: Yup, we're all scratching our heads right now at some weirdness
: going on with select()/poll(), but all we can see is the kernel
: primitives. *sigh* Our job would be a lot easier if we had
: pstack. =)
:
:So the question is, does ktrace in fact have this functionality? He's talking
:about LWPs, which I am assuming (please correct me if I am wrong) equates to
:libc_r on FreeBSD.
:
:Fwiw, I'm asking as an interested 3rd party. Thanks!
:
:> -Matt
:
:--
:Jos Backus _/ _/_/_/ Santa Clara, CA
: _/ _/ _/
: _/ _/_/_/
: _/ _/ _/ _/
:[EMAIL PROTECTED] _/_/ _/_/_/ use Std::Disclaimer;
Hmm. I'm looking at the code. We do have a utrace() system call
which allows a userland process to create a tracing record.
In regards to light weight processes, or threads as we call them,
with libc_r they are of course longjmp/select-or-poll-based rather
then rfork() based. ktrace effectively only logs the process id, found
in ktr_header (see sys/ktrace.h), but it should be possible to create
a userland structure that we log with utrace() that includes the
thread id whenever libc_r does an internal context switch. kdump()
could then detect this and supply the proper thread id.
It also would not be too big a deal to change the ktrace header
structure to include additional information. We actually have a
garbage caddr_t stored in there that holds the kernel buffer address
but is also written out to the file. That space could be reclaimed
to store a thread id (in the tracing file) but there would still have
to be some way for libc_r to register the thread id during a context
switch. Using utrace() is kinda hokey. A new system call or something.
I dunno about pstack. What does it do? Dump stack backtraces for
the threads? libc_r does use a fairly well-defined thread stack
arrangement. It should be possible to write a program (or a gdb
script) to track the stacks down and dump their backtraces.
Tracing userland procedure calls is more difficult. I do not believe
that the i386 has a separate trace trap for subroutine calls, it just
has a single-step trace trap, so a userland trace would have to be
built into the program (e.g. like profiling is with -pg).
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
