Date: Mon, 19 Apr 2010 08:46:33 -0400 From: jhell <jhell@dataix.net> To: Alexander Leidinger <netchild@freebsd.org> Cc: freebsd-current@freebsd.org, Navdeep Parhar <nparhar@gmail.com> Subject: Re: Does "makeoptions WITH_CTF=yes" actually work? Message-ID: <4BCC50A9.6090003@dataix.net> In-Reply-To: <20100416155140.21425jmdvmha7z40@webmail.leidinger.net> References: <g2md04e16b71004140133ubee176eboe6baaeb7ef0f0605@mail.gmail.com> <20100414105819.13143mf12ccgjy4g@webmail.leidinger.net> <y2vd04e16b71004140231u4b638141w17215bf037a9c94@mail.gmail.com> <20100414132342.74616nl7805cljgo@webmail.leidinger.net> <20100414183540.GA2542@gypsy> <20100416155140.21425jmdvmha7z40@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04/16/2010 09:51, Alexander Leidinger wrote:
> Quoting Navdeep Parhar <nparhar@gmail.com> (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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BCC50A9.6090003>