From owner-freebsd-current@FreeBSD.ORG Wed Nov 14 15:38:20 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD7D3651; Wed, 14 Nov 2012 15:38:20 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 5BE298FC13; Wed, 14 Nov 2012 15:38:19 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qAEFcJUi094194; Wed, 14 Nov 2012 08:38:19 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qAEFcHub023744; Wed, 14 Nov 2012 08:38:17 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: compiler info in kernel identification string From: Ian Lepore To: Dimitry Andric In-Reply-To: <50A3639C.9050200@FreeBSD.org> References: <20121113234303.GA15319@dft-labs.eu> <50A3639C.9050200@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Wed, 14 Nov 2012 08:38:17 -0700 Message-ID: <1352907497.1217.147.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Mateusz Guzik , avg@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Wed, 14 Nov 2012 15:38:20 -0000 On Wed, 2012-11-14 at 10:25 +0100, Dimitry Andric wrote: > On 2012-11-14 00:43, Mateusz Guzik wrote: > > avg@ suggested to include compiler version in the kernel so that it's > > present in uname (and one can easly tell what was used to compile it). > > > > Here is my attempt: > > http://people.freebsd.org/~mjg/patches/newvers-compiler.diff > > > > Basically adds compiler name and version/revision after revision of > > system sources. > > > > Sample output from dirty git sources: > > gcc: > > FreeBSD 10.0-CURRENT #7 r242962=264d569-dirty(gcc-4.2.1-20070831): Wed > > Nov 14 00:11:51 CET 2012 > > > > clang: > > FreeBSD 10.0-CURRENT #8 r242962=264d569-dirty(clang-r162107): Wed Nov 14 > > 00:12:26 CET 2012 > > > > Sample output from svn with gcc: > > FreeBSD 10.0-CURRENT #1 r243006:243007M(gcc-4.2.1-20070831): Wed Nov 14 > > 00:41:23 CET 2012 > > > > I have no strong opinions on format, I just want this information easly > > accessible. > > Yes, this is handy to have. Note that gcc already puts an id string > into each object file it produces, but sometimes during linking, these > can be stripped out... > > Regarding the format, I don't see the necessity of parsing the version > information, which will always be very fragile. Just include the > complete version string in the compiler identification, similar to what > Linux does, e.g. on a CentOS box: > > $ gcc -v 2>&1 | grep 'version ' > gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) > > $ dmesg | grep 'gcc version ' > Linux version 2.6.32-279.2.1.el6.x86_64 (mockbuild@c6b7.bsys.dev.centos.org) (gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) ) #1 SMP Fri Jul 20 01:55:29 UTC 2012 > > That way, you are sure never to lose information. This also works for > gcc from ports (which is the reason for the space after 'version' in the > grep command): > > $ gcc47 -v 2>&1 | grep 'version ' > gcc version 4.7.3 20120929 (prerelease) (FreeBSD Ports Collection) > > I realize this is a bit long, but it is better to have complete than > stripped information. Rather than just taking whatever the compiler emits, the proposed patch seems to be carefully crafted to avoid breaking existing 3rd party tools which parse uname output based on the location of whitespace. I'm not sure how important that is given that the uname manpage doesn't document the output format as if it were somehow rigidly specified. I may be more sensitive to this than usual right now, after having caused a bunch of grief to our manufacturing folks at work yesterday by removing a useless line of output about an obsolete feature from a script that I didn't realize they use in their automation. -- Ian