From owner-freebsd-current@FreeBSD.ORG Mon Apr 19 12:46:37 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D94471065670 for ; Mon, 19 Apr 2010 12:46:37 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id A267B8FC34 for ; Mon, 19 Apr 2010 12:46:37 +0000 (UTC) Received: by pvc7 with SMTP id 7so3083033pvc.13 for ; Mon, 19 Apr 2010 05:46:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=3SukUKADq7UB1jjSoT4fAqItDhme0cUpjJUELTuCNDY=; b=YBKW3fJxGRdENnO5myqHP6H5stGRrV4UQN8zIlVgFhde5mXRTM0we8f7J6yBtDnqhl bhKH7an/fEXz8a1YIIOr7GbUGvq0VuD7fV6Sc1MbRjUbcwWY/YZwnPWggvPzZZ62dRpj MzEdHfilToOLcRLfa2QSEpKbQzMy4HIVaA5iI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=tuzTzDKU/ZfIONCW7/7337ldHGRgbbm51R62k7w0r8I33rNOv8BDmVb0Ai6H2Ni0zg WGOxW8uzYVD/M11+ZtVivs55oCk90L4I3590szAXVY2NhMusrrztWrsQKGx7+8kYc+yc RKuNKN2EgY/j9hbPyczIPWB/W56zVIPeoTKqk= Received: by 10.140.252.3 with SMTP id z3mr3949422rvh.285.1271681196819; Mon, 19 Apr 2010 05:46:36 -0700 (PDT) Received: from centel.dataix.local (c-71-205-129-194.hsd1.mi.comcast.net [71.205.129.194]) by mx.google.com with ESMTPS id 21sm3959850qyk.9.2010.04.19.05.46.35 (version=SSLv3 cipher=RC4-MD5); Mon, 19 Apr 2010 05:46:35 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4BCC50A9.6090003@dataix.net> Date: Mon, 19 Apr 2010 08:46:33 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100331 Thunderbird/3.0.4 MIME-Version: 1.0 To: Alexander Leidinger References: <20100414105819.13143mf12ccgjy4g@webmail.leidinger.net> <20100414132342.74616nl7805cljgo@webmail.leidinger.net> <20100414183540.GA2542@gypsy> <20100416155140.21425jmdvmha7z40@webmail.leidinger.net> In-Reply-To: <20100416155140.21425jmdvmha7z40@webmail.leidinger.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Navdeep Parhar Subject: Re: Does "makeoptions WITH_CTF=yes" actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 12:46:37 -0000 On 04/16/2010 09:51, Alexander Leidinger wrote: > Quoting Navdeep Parhar (from Wed, 14 Apr 2010 > 11:35:40 -0700): > >> Have you or anyone else ever used buildkernel successfully with >> "makeoptions WITH_CTF=yes" in the conf file? Something as simple as >> this does not work for me: > > Copy&paste patch, tabs probbly mangled: > ---snip--- > Index: Makefile.inc1 > =================================================================== > --- Makefile.inc1 (revision 206700) > +++ Makefile.inc1 (working copy) > @@ -314,7 +314,7 @@ > .endif > > # kernel stage > -KMAKEENV= ${WMAKEENV} > +KMAKEENV= ${WMAKEENV:NNO_CTF=1} > KMAKE= ${KMAKEENV} ${MAKE} KERNEL=${INSTKERNNAME} > > # > @@ -780,7 +780,7 @@ > @echo > "--------------------------------------------------------------" > cd ${KRNLOBJDIR}/${_kernel}; \ > MAKESRCPATH=${KERNSRCDIR}/dev/aic7xxx/aicasm \ > - ${MAKE} SSP_CFLAGS= -DNO_CPU_CFLAGS -DNO_CTF \ > + ${MAKE} SSP_CFLAGS= -DNO_CPU_CFLAGS \ > -f ${KERNSRCDIR}/dev/aic7xxx/aicasm/Makefile > # XXX - Gratuitously builds aicasm in the ``makeoptions NO_MODULES'' case. > .if !defined(MODULES_WITH_WORLD) && !defined(NO_MODULES) && > exists(${KERNSRCDIR}/modules) > ---snip--- > > This lets the buildkernel generate ctf info in the object files (the > build is not finished yet, so I still have to verify that the final > kernel contains them too, but I do not see a reason ATM why this should > not be the case). > > If your build environment is faster (here: about an hour for the > buildkernel), can you please help testing? A buildworld with and without > WITH_CTF in src.conf, and for buildkernel the same (with and without > WITH_CTF in src.conf, and for each with and without makeoptions > WITH_CTF=yes in the kernel). The expected outcome is no CTF when no > WITH_CTF is in src.conf (except for the buildkernel with the > makeoptions), and always with CTF when WITH_CTF is in src.conf > (alternatively only CTF if makeoptions is used, but this would be > surprising for me). > > And then... NO_CTF=yes defined in src.conf and WITH_CTF too... for the > world this should not produce CTF data, but for the kernel I'm not sure > what will or should happen for the makeoptions case... > > Bye, > Alexander. > This sounds like a case of too many knobs to control whether ctfconvert will be used on any resulting object code. Couldn't this be better handled by defaulting WITH_CTF:=NO instead of having it act Boolean and set NO_CTF to 0 or 1 but rather check if we are building world or kernel by other means if the user has WITH_CTF defined somewhere else?. Or just check whether WITH_CTF is defined and enable the proper sections of the build for kernel. As I see in sys.mk: stable/7 example and not touched on HEAD. # Turn CTF conversion off by default for now. This default could be # changed later if DTrace becomes popular. .if !defined(WITH_CTF) NO_CTF = 1 .endif # C Type Format data is required for DTrace CTFFLAGS ?= -L VERSION .if !defined(NO_CTF) CTFCONVERT ?= ctfconvert CTFMERGE ?= ctfmerge .if defined(CFLAGS) && (${CFLAGS:M-g} != "") CTFFLAGS += -g .else CFLAGS += -g .endif .endif ### END OF PIECE ### Could be simplified: .if defined(WITH_CTF) CTFFLAGS ?= -L VERSION CTFCONVERT ?= ctfconvert CTFMERGE ?= ctfmerge CTFCONVERT ?= ctfconvert CTFMERGE ?= ctfmerge .if defined(CFLAGS) && (${CFLAGS:M-g} != "") CTFFLAGS += -g .else CFLAGS += -g .endif And this would leave little confusion about what is actually happening and ensure that adding something like (makeoptions -DWITH_CTF) actually work. I do not see a real need for NO_CTF if we can check to see if WITH_CTF is being defined. For the relevant sections of the tree that should never have WITH_CTF just dont add the ability to check and enable it. Or undefine it. JM2C Regards, -- jhell