Date: Mon, 22 Mar 2010 17:21:04 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: John Baldwin <jhb@freebsd.org> 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: <20100322172104.14234yawbsev0sw8@webmail.leidinger.net> In-Reply-To: <201003220941.10525.jhb@freebsd.org> References: <E1Nnv0H-00020A-9M@kabab.cs.huji.ac.il> <201003100812.29749.jhb@freebsd.org> <20100322123408.16671ijbvmcyux80@webmail.leidinger.net> <201003220941.10525.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting John Baldwin <jhb@freebsd.org> (from Mon, 22 Mar 2010 09:41:10 -0400): > On Monday 22 March 2010 7:34:08 am Alexander Leidinger wrote: >> Redirecting from stable@ to arch@... >> >> Quoting John Baldwin <jhb@freebsd.org> (from Wed, 10 Mar 2010 08:12:29 > -0500): >> >> > 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: >> >> > >> >> >>> From this you can see that sys.mk is included and parsed before >> > 'Makefile', >> >> >>> so the WITH_CTF=yes 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 :-). >> >> Ok, here is the proposal in form of a patch. :-) >> http://www.leidinger.net/test/ctf.diff >> >> > Unfortunately the ctf stuff breaks static binaries. I think that if >> > that were >> > fixed we would simply enable it by default and be done. >> >> 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 > > 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 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. 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. > 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. 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? 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? Is bsd.kern.mk included in module builds too? To make sure I get your and Scott's points right: - all opt-in - enabled for the kernel/mods via "makeoptions WITH_CTF=yes" in the kernel config instead of enabling it by default (maybe in bsd.kern.mk?) 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). I have a look at getting some time this week to rework the patch according to the outcome of the discussion here. Bye, Alexander. -- This fortune would be seven words long if it were six words shorter. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100322172104.14234yawbsev0sw8>