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

[Alexander Leidinger]

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 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