To John Birrell: weird behaviors of DTrace on amd64

[Robert Watson]

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:
>
> fbt::isp_handle_platform_atio2:entry
> {
> self->cdb =args[1]->at_cmnd.cdb_dl.sf.fcp_cmnd_cdb[0];
> 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
Computer Laboratory
University of Cambridge