Re: To John Birrell: weird behaviors of DTrace on amd64
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
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: To John Birrell: weird behaviors of DTrace on amd64
Hi Robert,
I rebuilt kernel with -fno-inline and I got all isp(4) functions listed in fbt.
I noticed that there are other inline related flags
--finline-limit=8000 -param inline-unit-growth=100 -Winline. should
I get rid of them OR -fno-inline
will just overide them ?
Thanks,
anyone has suggestion for problem 2 ?
On Fri, Feb 6, 2009 at 7:46 AM, Robert Watson rwat...@freebsd.org wrote:
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
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
To John Birrell: weird behaviors of DTrace on amd64
Hi John Birrell,
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 ?
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.
---
dtrace:::BEGIN
{
tr = 0;
}
fbt:::entry
/tr == 1/
{
@a[probefunc] = count();
}
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);
}
Thanks,
K. Zhu
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
