Date: Sun, 25 Apr 2004 12:11:54 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Stephen McKay <smckay@internode.on.net> Cc: freebsd-current@FreeBSD.org Subject: Re: what /boot/kernel/kernel output Message-ID: <20040425113401.U12952@gamplex.bde.org> In-Reply-To: <200404240238.i3O2capL005181@dungeon.home> References: <200404240238.i3O2capL005181@dungeon.home>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 24 Apr 2004, Stephen McKay wrote:
> [This is a resend. My first attempt appears to have been eaten. Sorry
> if this is the 2nd copy for you.]
I saw the first one later.
> For as long as I can remember, running the SCCS command "what" on the
> kernel of the day produced useful output: a single line fairly similar
> to "uname -v" but not quite so verbose. It works up until FreeBSD 5.2.1
> (at least) but fails for current.
>
> It fails because a hack in the constructed file "vers.c" no longer
> works. Here is a fix to the hack:
>
> --- newvers.sh.old Wed Apr 14 13:01:18 2004
> +++ newvers.sh Fri Apr 23 22:55:04 2004
> @@ -85,7 +85,7 @@
> i=`make -V KERN_IDENT`
> cat << EOF > vers.c
> $COPYRIGHT
> -char sccspad[32 - 4 /* sizeof(sccs) */] = { '\\0' };
> +char sccspad[32 - 4 /* sizeof(sccs) */] = { '\\1' };
> char sccs[4] = { '@', '(', '#', ')' };
> char version[] = "${VERSION} #${v}: ${t}\\n ${u}@${h}:${d}\\n";
> char ostype[] = "${TYPE}";
>
> Without this, sccspad is put in the BSS. I note that NetBSD solved
> this by duplicating the version string, one copy with @(#) and one
> without. Perhaps this is better than second guessing the whims of
> the compiler.
Euww. Almost anything is better. Your change seems to be to work
around gcc now putting zero data in the bss. I noticed the following
nearby bogusness:
- strings with local scope are not declared static.
- const strings are not declared const.
- initializer { '\\0' } has no effect.
- sccspad[] seems to be to work around gcc optimizing for space bloat
by aligning long strings like the one in version[].
- the alignment for long strings is potentially very MD. 32 is for
i386's. I don't know if it works for other arches.
- the alignment of 32 is not even for i386's, since we use
-mno-align-long-strings on i386's (unless CC is spelled "icc") to
avoid the optimization.
- the alignment of 32 is not even not for i386's, since
-mno-align-long-strings is broken.
- if the compiler is icc but CC is not spelled "icc", then we use the
invalid option -mno-align-long-strings.
- if we are chummy with gcc then we can just use its alignment attribute
to avoid the padding.
> Secondly, the output of "what" now has extraneous lines:
>
> $RCSfile: if_em_hw.h,v $$Revision: 1.37 $$Date: 2003/12/20 00:14:51 $
>
> which is printed twice.
>
> To solve this, we could #define NO_VERSION_CONTROL or simply delete
> the @(#) characters in line 45 in dev/em/if_em_hw.h.
This seems to be working (except it is a bug for headers to define data)
-- "what" shows you all 3 sccsids in the kernel :-).
> So, is this one tradition that still exists, or does this go in my
> growing collection of personal hacks? Should I patch either or both
> of these? The quick hack or the NetBSD way?
Use the NetBSD fix, and negotiate the fix for em with its maintainer.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040425113401.U12952>