On Mon, Oct 15, 2007 at 10:12:09AM -0400, Brian Utterback wrote: > I have a dtrace script (the funky one that iterates over the > speculation buffers) that has an fbt entry probe for the kernel > function cv_wait_sig_swap. Only it didn't trace anything even though > there was a process that hung in the function. Getting a thread stack > trace, I discovered that cv_wait_sig_swap didn't appear on the stack, > but cv_wait_sig_swap_core did. Looking at cv_wait_sig_swap and > cv_wait_sig_swap, I found that cv_wait_sig_swap is really just a > wrapper that calls cv_wait_sig_swap_core with the addition of > a single new parameter that is always set to NULL. So, the compiler > does not create a new frame for it, it just sets the parameter and > calls cv_wait_sig_swap_core, presumably leaving the old return address > in place.
Yes. On SPARC, the compiler seems to generate a tail-call in cv_wait_sig_swap() to cv_wait_sig_swap_core(). This means that you won't see cv_wait_sig_swap_core() in the stack backtrace. Adam -- Adam Leventhal, FishWorks http://blogs.sun.com/ahl _______________________________________________ dtrace-discuss mailing list [email protected]
