To John Birrell: weird behaviors of DTrace on amd64
rwatson at FreeBSD.org
Fri Feb 6 04:46:59 PST 2009
On Thu, 5 Feb 2009, Klapper Zhu wrote:
> I am exploring DTrace on "7.1-STABLE FreeBSD amd64" and I found several
> weird behaviors:
> 1) Not all kernel functions show up in fbt provider. Take isp(4) as example:
> "dtrace -l" shows
> static void isp_freeze_loopdown(ispsoftc_t *, int, char *);
> ___but not___
> static void isp_handle_platform_atio2(ispsoftc_t *, at2_entry_t *);
> Both are static functions. But one shows up in fbt, another not.
> What's the rational behind it ? Any way to fix it ?
Possibly gcc decided to inline one but not the other; you could try disabling
inlining and see if the other function appears. fbt is sensitive to a number
of compiler choices, so generally if there's a long-term desire to trace at
that point, we should add explicit trace points. (Solaris makes similar
recommendations -- that fbt is a useful but unstable interface).
> 2) The symptom described below only shows in 64-bit platform (amd64).
> Here is the D Code:
> self->cdb =args->at_cmnd.cdb_dl.sf.fcp_cmnd_cdb;
> printf("%s(%x, %x, cdb_cmd %x)\n", probefunc, arg0, arg1, self->cdb);
> It will never fire.
> I have to add another 2 probes on top of it, then it
> (fbt::isp_handle_platform_atio2:entry) will trace.
> Even the 2 probes on top of it never fire.
I've seen a number of cases where entry fbt points fire but return fbt points
don't; for example, in 8.x I've noticed that fbt::softclock:enter fires each
time the softclock loop runs, even though the function is only entered once
when the kernel thread starts, and that it never fires the return. This
suggests fbt may be putting the probe in the wrong spot, perhaps the beginning
of the block where local variables are used rather than the beginning of the
function itself. I've reported this problem to John also.
Robert N M Watson
University of Cambridge
More information about the freebsd-stable