CTF patch for testing/review (was: Re: is dtrace usable?)

[Scott Long]

On Mar 22, 2010, at 10:21 AM, Alexander Leidinger wrote:
> Quoting John Baldwin <jhb at 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 at ...
>>> 
>>> Quoting John Baldwin <jhb at 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 at 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 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