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>
index | next in thread | previous in thread | raw e-mail
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
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040425113401.U12952>