Date: Fri, 6 Feb 2009 13:22:36 -0500 From: Klapper Zhu <klapperzhu@gmail.com> To: Robert Watson <rwatson@freebsd.org> Cc: freebsd-stable@freebsd.org Subject: Re: To John Birrell: weird behaviors of DTrace on amd64 Message-ID: <a29c138b0902061022v40301c34v8f5b7edcb5c16395@mail.gmail.com> In-Reply-To: <alpine.BSF.2.00.0902061243230.6471@fledge.watson.org> References: <a29c138b0902050831q13844f7bm3aa3bdebdcb9733e@mail.gmail.com> <a29c138b0902050857o1d6062fdwffe77eccdd4c622a@mail.gmail.com> <alpine.BSF.2.00.0902061243230.6471@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <rwatson@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
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a29c138b0902061022v40301c34v8f5b7edcb5c16395>