From owner-freebsd-stable@FreeBSD.ORG Fri Feb 6 18:22:37 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 986F3106566B for ; Fri, 6 Feb 2009 18:22:37 +0000 (UTC) (envelope-from klapperzhu@gmail.com) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.189]) by mx1.freebsd.org (Postfix) with ESMTP id 3DA6D8FC18 for ; Fri, 6 Feb 2009 18:22:37 +0000 (UTC) (envelope-from klapperzhu@gmail.com) Received: by rn-out-0910.google.com with SMTP id k32so623633rnd.12 for ; Fri, 06 Feb 2009 10:22:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=n3KxWIkpYUJasTNTcVOl+Kqut6GHDps2zNhJJW/9lec=; b=xyHZwjwghrXoeNZN7MgOy6lGN060PvboumNwOF2ZylWb6Lu1WacVBzLyeFIX0u6Fj5 sZMv4acUpFFmymyXWAMsG/jc4guctApuPp774DXLWIYG+RsnA3aSWeDsV34A7NEIdlln TZ6Yq/ktm0crjEQj5Vn/UbovQ3xjp4oRxeOH0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YklrAsXVZj7JsbxPukc6guSAEDq4Tp6/mhwlx62qvnAJ/LK5Ej65i6n3ADRYacC0rT 6v5pRmLZkAEfr5+PQe1EphI8yRiQMogfXulkx0n08r0MVy7AGOAKe7TnV74eW0IybNHT sqDpcWBxF7gIeJIMxJiaNoNwL8yTqfnO+qfWw= MIME-Version: 1.0 Received: by 10.151.46.17 with SMTP id y17mr502384ybj.211.1233944556667; Fri, 06 Feb 2009 10:22:36 -0800 (PST) In-Reply-To: References: Date: Fri, 6 Feb 2009 13:22:36 -0500 Message-ID: From: Klapper Zhu To: Robert Watson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: To John Birrell: weird behaviors of DTrace on amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 18:22:38 -0000 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 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 >