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

[John Baldwin]

On Monday 22 March 2010 12:21:04 pm 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.

Just about any port that doesn't use gmake.  Also, anyone who writes a foo.c 
and types 'make foo' to get automatic rules.  I think we should only enable 
CTF in stages.  To do that safely, it needs to be opt-in in sys.mk.  We can 
then work on changing the defaults in certain places (e.g. bsd.kern.mk and 
bsd.kmod.mk) to enable it for kernel builds and modules.  Eventually we could 
enable it by default in bsd.prog.mk and bsd.lib.mk if desired, but I think 
those should be future steps.  I think your patch has promise as being a good 
approach, but it ctf needs to be off-by-default in sys.mk.

-- 
John Baldwin