CTF patch for testing/review

John Baldwin jhb at freebsd.org
Wed Mar 24 14:15:45 UTC 2010


On Wednesday 24 March 2010 9:59:41 am Alexander Leidinger wrote:
> Quoting John Baldwin <jhb at freebsd.org> (from Tue, 23 Mar 2010 10:25:55 -0400):
> 
> > On Tuesday 23 March 2010 6:12:43 am Alexander Leidinger wrote:
> >> Quoting "M. Warner Losh" <imp at bsdimp.com> (from Mon, 22 Mar 2010
> >> 20:35:53 -0600 (MDT)):
> >>
> >> > In message: <201003221605.24538.jhb at freebsd.org>
> >> >             John Baldwin <jhb at FreeBSD.org> writes:
> >> > : On Monday 22 March 2010 3:05:12 pm M. Warner Losh wrote:
> >> > : > In message: <20100322.125937.278730673160410010.imp at bsdimp.com>
> >> > : >             M. Warner Losh <imp at bsdimp.com> writes:
> >> > : > : In message: <20100322172104.14234yawbsev0sw8 at webmail.leidinger.net>
> >> > : > :             Alexander Leidinger <Alexander at Leidinger.net> writes:
> >> > : > : : 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?
> >> > : > :
> >> > : > : Normally we *TEST* MK_XXX for things which are opt-in/opt-out and
> >> > : > : require the user to say WITH_XXX or WITHOUT_XXX if they don't like
> > the
> >> > : > : default (or want to ensure they get option XXX, even if we turn it
> > off
> >> > : > : by default in the future).  The default then gets encoded in
> >> > : > : bsd.own.mk, and permeates the FreeBSD build system since we include
> >> > : > : that everywhere, directly or indirectly.
> >> > : > :
> >> > : > : The problem is that bsd.own.mk is not included in sys.mk, nor should
> >> > : > : it be.  That's why we have the hacky combination of WITH_CTF and
> >> > : > : NO_CTF that's there today.
> >> > : > :
> >> > : > : : Is bsd.kern.mk included in module builds too?
> >> > : > :
> >> > : > : Yes.
> >> > : >
> >> > : > One last thing I should have said was that the patch that was posted
> >> > : > earlier in the thread looked ok, and likely couldn't be made
> >> > : > significantly better due to the bsd.own.mk issue.
> >> > :
> >> > : I think the patch is a good approach, I just think it needs to
> >> > default to not
> >> > : enabling CTF by default.  Instead, various bsd.foo.mk should selectively
> >> > : enable it.
> >> >
> >> > I should have added that bit as well...
> >>
> >> And here it is:
> >>    http://www.leidinger.net/test/ctf2.diff
> >>
> >> Please pay attention to one XXX comment. Both cases I describe look
> >> possible, but I would like to get some more eyes on this issues to not
> >> overlook something.
> >
> > I would maybe put a comment in front of the CFLAGS+= line for now and leave
> > the rest of the XXX comment.  I'm not sure of the best way to solve this yet.
> 
> Done. I want to have a look if it is possible to do it similar to the  
> LD_CTF_FLAG way later.
> 
> Currently I have the problem that WITH_CTF is not picked up by kmod.mk  
> if "makeoptions WITH_CTF=yes" is used in the kernel config. This means  
> that all makeoptions do not propagate to module builds.
> 
> Any ideas?

Hmmmm.  That's odd because 'DEBUG=-g' does work.  Ah, I think you should
patch kern.post.mk to propogate WITH_CTF to modules.  This is how it works
for DEBUG now:

.if defined(DEBUG)
MKMODULESENV+=  DEBUG_FLAGS="${DEBUG}"
.endif

-- 
John Baldwin


More information about the freebsd-arch mailing list