On Mon, Aug 30, 2010 at 12:29:18PM -0500, Nicolas Williams wrote: > On Mon, Aug 30, 2010 at 10:17:53AM -0700, Jonathan Adams wrote: > > On Fri, Aug 27, 2010 at 04:44:31PM -0700, Rafael Vanoni wrote: > > > I was trying to aggregate on the stack trace of a CPU's current > > > thread from a cpu_t * and the best I could do was aggregating with > > > sym() on the t_startpc field of the CPU's current thread. > > > > > > It doesn't look like it would be very difficult to write a new > > > action to get stack() from a given CPU id. Would that be of interest > > > to anyone else? If so, please let me know and I'll write it up. > > > > It is extremely difficult to do that from another CPU on SPARC, since > > register windows mean that much of the stack state is kept in-CPU. Even > > on x86, you can't get anything better than the last place the thread updated > > its t_pcb (e.g. in cv_wait()), and there's a good chance the stack won't > > line > > up. > > Can't this be done with dtrace_xcall()?
You can't cross-call from probe context, let alone wait for one to complete. dtrace_xcall() is used by the dtrace infrastructure to ensure that any in-flight dtrace_probe()s while a state change was happening have completed before continuing on to the next step. > BTW, another backtrace-like action I'd love to see would be something > like ptree(), which would output ptree(1)-like output (but without > program arguments) that could then be aggregated on. That could be handy. Cheers, - jonathan _______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
