Date: Sat, 24 Dec 2011 23:40:09 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Alexander Best <arundel@FreeBSD.ORG> Cc: Adrian Chadd <adrian@FreeBSD.ORG>, freebsd-current@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: [rfc] removing -mpreferred-stack-boundary=2 flag for i386? Message-ID: <20111224225717.P2417@besplex.bde.org> In-Reply-To: <20111224114714.GA29325@freebsd.org> References: <20111223235642.GA37495@freebsd.org> <20111224160050.T1141@besplex.bde.org> <CAJ-VmokbKMBXW2ppEK_tC-OdepHmQT0cF=UuQdxBg=U8t=qmVQ@mail.gmail.com> <20111224211903.I2059@besplex.bde.org> <20111224114714.GA29325@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 24 Dec 2011, Alexander Best wrote:
> On Sat Dec 24 11, Bruce Evans wrote:
>> This almost builds in -current too. I had to add the following:
>> - NO_MODULES to de-bloat the compile time
>> - MK_CTF=no to build -current on FreeBSD.9. The kernel .mk files are
>> still broken (depend on nonstandard/new features in sys.mk).
>
> strange. the build(7) man page claims that:
>
> "
> WITH_CTF If defined, the build process will run the DTrace CTF
> conversion tools on built objects. Please note that
> this WITH_ option is handled differently than all other
> WITH_ options (there is no WITHOUT_CTF, or correspond-
> ing MK_CTF in the build system).
> "
>
> ... so setting MK_CTF to anything shouldn't have (according to the man page).
MK_CTF is an implementation detail. It is normally set in bsd.own.mk
(not in sys.mk line I said -- this gives another, much larger bug (*)).
But when usr/share/mk is old, it doesn't know anything about MK_CTF.
(For example, in FreeBSD-9, sys.mk sets NO_CTF to 1 if WITH_CTF is not
defined. This corresponds to bsd.own.mk in -current setting MK_CTF
to "no" if WITH_CTF is not defined. Go back to an older version of
FreeBSD and /usr/share/mk/* won't know anything about any CTF variable.)
So when you try to build a current kernel under an old version of
FreeBSD, MK_CTF is used uninitialized and the build fails. (Of course,
"you" build kernels normally and don't use the bloated buildkernel
method.) The bug is in the following files:
kern.post.mk:.if ${MK_CTF} != "no"
kern.pre.mk:.if ${MK_CTF} != "no"
kmod.mk:.if defined(MK_CTF) && ${MK_CTF} != "no"
except for the last one where it has been fixed.
(*) Well, not completely broken, but just annoyingly unportabile.
Consider the following makefile:
%%%
foo: foo.c
%%%
Invoking this under FreeBSD-9 gives:
%%%
cc -O2 -pipe foo.c -o foo
[ -z "ctfconvert" -o -n "1" ] || (echo ctfconvert -L VERSION foo && ctfconvert -L VERSION foo)
%%%
This is the old ctf method. It is ugly but is fairly portable.
Invoking this under FreeBSD-9 but with -m<path-to-current-mk-directory> gives
%%%
cc -O2 -pipe foo.c -o foo
${CTFCONVERT_CMD} expands to empty string
%%%
This is because:
- the rule in sys.mk says ${CTFCONVERT_CMD}
- CTFCONVERT_CMD is normally defined in bsd.own.mk. But bsd.own.mk is only
included by BSD makefiles. It is never included by portable makefiles.
So ${CTFCONVERT_CMD} is used uninitialized.
- for some reason, using variables uninitialized is not fatal in this
context, although it is for the comparisons of ${MK_CTF} above.
- ${CTFCONVERT_CMD} is replaced by the empty string. Old versions of
make warn about the use of an empty string as a shell command.
- the code that is supposed to prevent the previous warning is in
bsd.own.mk, where it is not reached for portable makefiles. It is:
% .if ${MK_CTF} != "no"
% CTFCONVERT_CMD= ${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
This uses the full ctfconvert if WITH_CTF.
% .elif ${MAKE_VERSION} >= 5201111300
% CTFCONVERT_CMD=
make(1) has been modified to not complain about the empty string. The
version test detects which versions of make don't complain.
% .else
% CTFCONVERT_CMD= @:
The default is to generate this non-empty string and an extra shell command
to execute it, for old versions of make.
% .endif
But none of this works for portable makefiles, since it is not reached.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111224225717.P2417>