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"