From owner-freebsd-current@FreeBSD.ORG Sat Apr 24 19:12:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FCC816A4CE for ; Sat, 24 Apr 2004 19:12:01 -0700 (PDT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0BE843D62 for ; Sat, 24 Apr 2004 19:12:00 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i3P2Bx5v021836; Sun, 25 Apr 2004 12:11:59 +1000 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i3P2BvI2025848; Sun, 25 Apr 2004 12:11:58 +1000 Date: Sun, 25 Apr 2004 12:11:54 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Stephen McKay In-Reply-To: <200404240238.i3O2capL005181@dungeon.home> Message-ID: <20040425113401.U12952@gamplex.bde.org> References: <200404240238.i3O2capL005181@dungeon.home> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@FreeBSD.org Subject: Re: what /boot/kernel/kernel output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Sun, 25 Apr 2004 02:12:01 -0000 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