From owner-freebsd-arch@FreeBSD.ORG Mon Mar 22 16:30:44 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AB24106566C; Mon, 22 Mar 2010 16:30:44 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id A76358FC18; Mon, 22 Mar 2010 16:30:43 +0000 (UTC) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.14.3/8.14.3) with ESMTP id o2MGUdOi050325; Mon, 22 Mar 2010 10:30:39 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <20100322172104.14234yawbsev0sw8@webmail.leidinger.net> Date: Mon, 22 Mar 2010 10:30:39 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201003100812.29749.jhb@freebsd.org> <20100322123408.16671ijbvmcyux80@webmail.leidinger.net> <201003220941.10525.jhb@freebsd.org> <20100322172104.14234yawbsev0sw8@webmail.leidinger.net> To: Alexander Leidinger X-Mailer: Apple Mail (2.1077) X-Spam-Status: No, score=-1.0 required=3.8 tests=ALL_TRUSTED autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: "Robert N. M. Watson" , freebsd-arch@freebsd.org Subject: Re: CTF patch for testing/review (was: Re: is dtrace usable?) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 16:30:44 -0000 On Mar 22, 2010, at 10:21 AM, Alexander Leidinger wrote: > Quoting John Baldwin (from Mon, 22 Mar 2010 09:41:10 = -0400): >=20 >> On Monday 22 March 2010 7:34:08 am Alexander Leidinger wrote: >>> Redirecting from stable@ to arch@... >>>=20 >>> Quoting John Baldwin (from Wed, 10 Mar 2010 = 08:12:29 >> -0500): >>>=20 >>> > On Wednesday 10 March 2010 5:34:22 am Alexander Leidinger wrote: >>> >> Quoting "Robert N. M. Watson" (from Tue, 9 = Mar >>> >> 2010 16:39:09 +0000): >>> >> >>> >> > >>> >> > On Mar 9, 2010, at 2:16 PM, Alexander Leidinger wrote: >>> >> > >>> >> >>> =46rom this you can see that sys.mk is included and parsed = before >>> > 'Makefile', >>> >> >>> so the WITH_CTF=3Dyes is not set until after sys.mk has been = parsed. >>> >> >> >>> >> >> I think we need to find a different solution for this. The = need to >>> >> >> specify WITH_CTF at the command line is very error prone. :( >>> >> > >>> >> > You are neither the first person to have made this observation, = nor >>> >> > the first person to have failed to propose a solution in the = form of >>> >> > a patch :-). >>>=20 >>> Ok, here is the proposal in form of a patch. :-) >>> http://www.leidinger.net/test/ctf.diff >>>=20 >>> > Unfortunately the ctf stuff breaks static binaries. I think that = if >>> > that were >>> > fixed we would simply enable it by default and be done. >>>=20 >>> The patch is: >>> - enabling CTF stuff by default for the kernel >>> - allows to disable the CTF stuff for the kernel by defining NO_CTF >>> - *not* enabling the CTF stuff by default for libs and progs >>> (if someone tells me how to distinguish the build for static >>> stuff from dynamic stuff, I can have a look to enable it for >>> the dynamic case) >>> - allows to enable the CTF stuff for the userland by defining >>> WITH_CTF as before >>=20 >> I think this patch looks very interesting. I think in some ways it = would be >> nice to make CTF "opt-in" though instead of "opt-out". I think the = current >> patch would enable CTF when building ports, for example. I think = instead it >=20 > If you talk about kernel modules: yes, this should enable CTF there. > If you talk about programs which use bsd.prog.mk or bsd.lib.mk: no, = this will not enable CTF. >=20 > The ports which use gmake will not be affected, I'm not sure about = ports which use our make but not bsd.prog.mk or bsd.lib.mk. Anyone with = an example of such a port which I could test? A quick query of portmgr = (miwi) via IM didn't produce an obvious candidate port. >=20 >> should default to not building CTF, but require an ENABLE_CTF = (instead of >> NO_CTF) to be set, and set that in bsd.kern.mk if WITH_CTF is = defined. >=20 > What about your previous "enabled by default" for kernel+world (yes, = my patch is asymmetric in that it only enables the kernel part as the = result of static userland stuff seems to have a problem), what's the = reason for the switch to opt-in? >=20 > Normally we use MK_xxx for things which are opt-in/opt-out. What about = using MK_xxx instead of ENABLE_CTF? If people are in favour of MK_xxx, = what should the xxx part look like? >=20 > Is bsd.kern.mk included in module builds too? >=20 > To make sure I get your and Scott's points right: > - all opt-in > - enabled for the kernel/mods via "makeoptions WITH_CTF=3Dyes" in the > kernel config instead of enabling it by default (maybe in > bsd.kern.mk?) >=20 > Note: the NO_CTF part is existing stuff, I probably would have to fix = other places too then. The current patch is a minimal patch to opt-out = for kernel builds and opt-in for prog/lib parts. The ports area needs to = be investigated (if nothing is affected, nothing needs to be taken into = account). >=20 I think it's still important to be opt-in for dtrace. If you're = reluctant, I'll submit my patch which is opt-in, and is only about 10 = lines of code change. Scott