Date: Mon, 22 Mar 2010 10:30:39 -0600 From: Scott Long <scottl@samsco.org> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: "Robert N. M. Watson" <rwatson@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: CTF patch for testing/review (was: Re: is dtrace usable?) Message-ID: <AAFAA7E3-25F5-4BDA-8618-9AE2431D0E51@samsco.org> In-Reply-To: <20100322172104.14234yawbsev0sw8@webmail.leidinger.net> References: <E1Nnv0H-00020A-9M@kabab.cs.huji.ac.il> <201003100812.29749.jhb@freebsd.org> <20100322123408.16671ijbvmcyux80@webmail.leidinger.net> <201003220941.10525.jhb@freebsd.org> <20100322172104.14234yawbsev0sw8@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 22, 2010, at 10:21 AM, Alexander Leidinger wrote: > Quoting John Baldwin <jhb@freebsd.org> (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 <jhb@freebsd.org> (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" <rwatson@freebsd.org> (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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AAFAA7E3-25F5-4BDA-8618-9AE2431D0E51>