Re: compiler info in kernel identification string

[Andriy Gapon]

on 15/11/2012 22:43 Andriy Gapon said the following:
 on 14/11/2012 01:43 Mateusz Guzik said the following:
 Hello,

 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
 
 When are you committing this?

It seems that this effort has stuck?..

Here is a change that I am using locally.  It doesn't change uname output at
all, but rather adds a compiler version string to the kernel banner.

I may even commit this :)

[test] print compiler version in the kernel banner

diff --git a/sys/conf/newvers.sh b/sys/conf/newvers.sh
index 5e83e1a..724f609 100644
--- a/sys/conf/newvers.sh
+++ b/sys/conf/newvers.sh
@@ -86,6 +86,7 @@ fi
 touch version
 v=`cat version` u=${USER:-root} d=`pwd` h=${HOSTNAME:-`hostname`} t=`date`
 i=`${MAKE:-make} -V KERN_IDENT`
+compiler_v=$($(${MAKE:-make} -V CC) -v 21 | grep 'version')

 for dir in /bin /usr/bin /usr/local/bin; do
if [ -x ${dir}/svnversion ]  [ -z ${svnversion} ] ; then
@@ -159,6 +160,7 @@ $COPYRIGHT

 char sccs[sizeof(SCCSSTR)  128 ? sizeof(SCCSSTR) : 128] = SCCSSTR;
 char version[sizeof(VERSTR)  256 ? sizeof(VERSTR) : 256] = VERSTR;
+char compiler_version[] = ${compiler_v};
 char ostype[] = ${TYPE};
 char osrelease[sizeof(RELSTR)  32 ? sizeof(RELSTR) : 32] = RELSTR;
 int osreldate = ${RELDATE};
diff --git a/sys/kern/init_main.c b/sys/kern/init_main.c
index 00b1c3f..a92b6db 100644
--- a/sys/kern/init_main.c
+++ b/sys/kern/init_main.c
@@ -325,6 +325,7 @@ print_version(void *data __unused)
while (len  0  version[len - 1] == '\n')
len--;
printf(%.*s %s\n, len, version, machine);
+   printf(%s\n, compiler_version);
 }

 SYSINIT(announce, SI_SUB_COPYRIGHT, SI_ORDER_FIRST, print_caddr_t,
diff --git a/sys/sys/systm.h b/sys/sys/systm.h
index fec77d2..3163b9f 100644
--- a/sys/sys/systm.h
+++ b/sys/sys/systm.h
@@ -49,6 +49,7 @@ extern int cold;  /* nonzero if we are doing a 
cold boot */
 extern int rebooting;  /* kern_reboot() has been called. */
 extern const char *panicstr;   /* panic message */
 extern char version[]; /* system version */
+extern char compiler_version[];/* system version */
 extern char copyright[];   /* system copyright */
 extern int kstack_pages;   /* number of kernel stack pages */


-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: compiler info in kernel identification string

[Mateusz Guzik]

On Sun, Dec 23, 2012 at 03:18:14PM +0200, Andriy Gapon wrote:
 on 15/11/2012 22:43 Andriy Gapon said the following:
  on 14/11/2012 01:43 Mateusz Guzik said the following:
  Hello,
 
  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
  
  When are you committing this?
 
 It seems that this effort has stuck?..
 
 Here is a change that I am using locally.  It doesn't change uname output at
 all, but rather adds a compiler version string to the kernel banner.
 

I had other patch in this thread that did exactly that + added
sysctl kern.compiler:

http://people.freebsd.org/~mjg/patches/compiler-info.diff

 I may even commit this :)


So, if that matters, I have no objections to your patch. However I'd like
to see kern.compiler-like sysctl added.

Also if you like feel free to take my patch and improve it (your compiler
detection seems to be more robust).

-- 
Mateusz Guzik mjguzik gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: compiler info in kernel identification string

[Erik Cederstrand]

Den 16/11/2012 kl. 08.34 skrev Andriy Gapon a...@freebsd.org:

 on 16/11/2012 01:09 Dimitry Andric said the following:
 And as I remarked in another reply, now that I have thought about it a
 bit, I would much rather see this information moved to a sysctl or dmesg
 line, than in uname.  With the happy side effect that no existing uname
 parsers would be confused!
 
 I would still like to have at least compiler's base name or type or 
 something
 in uname.

This has been brought up before, but what about putting all this in a separate 
file, e.g. /etc/buildinfo?

At least I'd like this to be configurable. I'm trying to get FreeBSD code in a 
shape where it can optionally produce deterministic binaries from two different 
builds (i.e. comparable with md5) as long as the binaries are functionally 
equivalent, and irrelevant info like compiler version, hostname, username, 
timestamp, absolute path etc. are a nuisance if they can't be turned off with 
-fno-ident, -frandom-seed, -DSTRIP_FBSDID, ar -D and the like.

Thanks,
Erik
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: compiler info in kernel identification string

[Andriy Gapon]

on 16/11/2012 11:20 Erik Cederstrand said the following:
 Den 16/11/2012 kl. 08.34 skrev Andriy Gapon a...@freebsd.org:
 
 on 16/11/2012 01:09 Dimitry Andric said the following:
 And as I remarked in another reply, now that I have thought about it a 
 bit, I would much rather see this information moved to a sysctl or dmesg 
 line, than in uname.  With the happy side effect that no existing uname 
 parsers would be confused!
 
 I would still like to have at least compiler's base name or type or
 something in uname.
 
 This has been brought up before, but what about putting all this in a
 separate file, e.g. /etc/buildinfo?

There is a chance this file could be out of sync with kernel.

 At least I'd like this to be configurable. I'm trying to get FreeBSD code in
 a shape where it can optionally produce deterministic binaries from two

This is a very good goal.  I also would like to see it achieved.

 different builds (i.e. comparable with md5) as long as the binaries are
 functionally equivalent, and irrelevant info like compiler version,

I agree about the following items, but not about compilers / compiler versions.
Different compilers can (and do) produce different binaries already (and
sometimes bugs).
While, indeed, time of compilation should not affect the binaries (unless the
phase of the Moon plays a role).

 hostname, username, timestamp, absolute path etc. are a nuisance if they
 can't be turned off with -fno-ident, -frandom-seed, -DSTRIP_FBSDID, ar -D and
 the like.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: compiler info in kernel identification string

[Daniel Braniss]

 on 16/11/2012 11:20 Erik Cederstrand said the following:
  Den 16/11/2012 kl. 08.34 skrev Andriy Gapon a...@freebsd.org:
  
  on 16/11/2012 01:09 Dimitry Andric said the following:
  And as I remarked in another reply, now that I have thought about it a 
  bit, I would much rather see this information moved to a sysctl or dmesg 
  line, than in uname.  With the happy side effect that no existing uname 
  parsers would be confused!
  
  I would still like to have at least compiler's base name or type or
  something in uname.
  
  This has been brought up before, but what about putting all this in a
  separate file, e.g. /etc/buildinfo?
 
 There is a chance this file could be out of sync with kernel.
 
  At least I'd like this to be configurable. I'm trying to get FreeBSD code in
  a shape where it can optionally produce deterministic binaries from two
 
 This is a very good goal.  I also would like to see it achieved.
 
  different builds (i.e. comparable with md5) as long as the binaries are
  functionally equivalent, and irrelevant info like compiler version,
 
 I agree about the following items, but not about compilers / compiler 
 versions.
 Different compilers can (and do) produce different binaries already (and
 sometimes bugs).
 While, indeed, time of compilation should not affect the binaries (unless the
 phase of the Moon plays a role).
 
  hostname, username, timestamp, absolute path etc. are a nuisance if they
  can't be turned off with -fno-ident, -frandom-seed, -DSTRIP_FBSDID, ar -D 
  and
  the like.
 

the question as to what compiler was used to compile the kernel is a bit of an
oxymoron, since the kernel is made up of many different modules, which get 
compiled
either by different compilers, or different compiler flags.

since the compiler does 'sign' the modules it compiles (and clang will/should
do it soon: http://llvm.org/bugs/show_bug.cgi?id=7292) some tool like
file(1) could be modified to provide it, or config -x (8) ...

IMHO, the only meaningfull information added to uname was the svn/git(and 
hopefully hg) rev. version.

as usual, my 3c,
danny



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: compiler info in kernel identification string

[Andriy Gapon]

This is starting to turn into a bikeshed, but anyway...

on 16/11/2012 12:00 Daniel Braniss said the following:
 the question as to what compiler was used to compile the kernel is a bit of an
 oxymoron, since the kernel is made up of many different modules, which get 
 compiled
 either by different compilers, or different compiler flags.

The canonical way to compile a kernel is to use buildkernel and compile modules
along with the kernel.  Other configurations are supported too, of course.

 since the compiler does 'sign' the modules it compiles (and clang will/should
 do it soon: http://llvm.org/bugs/show_bug.cgi?id=7292) some tool like
 file(1) could be modified to provide it, or config -x (8) ...

The key word in your note about clang is 'soon' as in 'not yet'.

Besides, when I see a bug report with a dmesg *I* want to immediately know what
compiler was used there.

 IMHO, the only meaningfull information added to uname was the svn/git(and 
 hopefully hg) rev. version.


-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: compiler info in kernel identification string

[Erik Cederstrand]

Den 16/11/2012 kl. 11.18 skrev Andriy Gapon a...@freebsd.org:

 This is starting to turn into a bikeshed, but anyway...
 
 on 16/11/2012 12:00 Daniel Braniss said the following:
 the question as to what compiler was used to compile the kernel is a bit of 
 an
 oxymoron, since the kernel is made up of many different modules, which get 
 compiled
 either by different compilers, or different compiler flags.
 
 The canonical way to compile a kernel is to use buildkernel and compile 
 modules
 along with the kernel.  Other configurations are supported too, of course.
 
 since the compiler does 'sign' the modules it compiles (and clang will/should
 do it soon: http://llvm.org/bugs/show_bug.cgi?id=7292) some tool like
 file(1) could be modified to provide it, or config -x (8) ...
 
 The key word in your note about clang is 'soon' as in 'not yet'.
 
 Besides, when I see a bug report with a dmesg *I* want to immediately know 
 what
 compiler was used there.

But wouldn't you want to know the compiler flags, too? And the kernel config 
file?  src.conf? Local patches? To solve a bug, in general you would want 
sufficient information to recreate the environment locally. Compiler version is 
not enough.

So either you have all information in every binary, because they might have 
been built outside a buildworld, or you have the general buildworld / 
buildkernel configuration in a central place and expect users to supply 
information about whatever non-standard setup they did.

Erik
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: compiler info in kernel identification string

[Daniel Braniss]

 
 This is starting to turn into a bikeshed, but anyway...
 
 on 16/11/2012 12:00 Daniel Braniss said the following:
  the question as to what compiler was used to compile the kernel is a bit of 
  an
  oxymoron, since the kernel is made up of many different modules, which get 
  compiled
  either by different compilers, or different compiler flags.
 
 The canonical way to compile a kernel is to use buildkernel and compile 
 modules

this does not guarantee uniformity, just look at the output it produces and 
you will see
different compilers/assemblers/scripts/flags

 along with the kernel.  Other configurations are supported too, of course.
 

  since the compiler does 'sign' the modules it compiles (and clang 
  will/should
  do it soon: http://llvm.org/bugs/show_bug.cgi?id=7292) some tool like
  file(1) could be modified to provide it, or config -x (8) ...
 
 The key word in your note about clang is 'soon' as in 'not yet'.
Dimitry wrote that he will handle it :-)

 
 Besides, when I see a bug report with a dmesg *I* want to immediately know 
 what
 compiler was used there.
today it's clang vs. gcc -- transition time --, but again it's only part of 
the story,
and soon it will only be noise.

 
  IMHO, the only meaningfull information added to uname was the svn/git(and 
  hopefully hg) rev. version.
 
 
 -- 
 Andriy Gapon


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: compiler info in kernel identification string

[Andriy Gapon]

[cc list trimmed]

on 16/11/2012 12:43 Erik Cederstrand said the following:
 Den 16/11/2012 kl. 11.18 skrev Andriy Gapon a...@freebsd.org:
 
 This is starting to turn into a bikeshed, but anyway...
 
 on 16/11/2012 12:00 Daniel Braniss said the following:
 the question as to what compiler was used to compile the kernel is a bit
 of an oxymoron, since the kernel is made up of many different modules,
 which get compiled either by different compilers, or different compiler
 flags.
 
 The canonical way to compile a kernel is to use buildkernel and compile
 modules along with the kernel.  Other configurations are supported too, of
 course.
 
 since the compiler does 'sign' the modules it compiles (and clang
 will/should do it soon: http://llvm.org/bugs/show_bug.cgi?id=7292) some
 tool like file(1) could be modified to provide it, or config -x (8) ...
 
 The key word in your note about clang is 'soon' as in 'not yet'.
 
 Besides, when I see a bug report with a dmesg *I* want to immediately know
 what compiler was used there.
 
 But wouldn't you want to know the compiler flags, too? And the kernel config
 file?  src.conf? Local patches? To solve a bug, in general you would want
 sufficient information to recreate the environment locally. Compiler version
 is not enough.

It depends.  OK?

 So either you have all information in every binary, because they might have
 been built outside a buildworld, or you have the general buildworld /
 buildkernel configuration in a central place and expect users to supply
 information about whatever non-standard setup they did.



-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: compiler info in kernel identification string

[Andriy Gapon]

on 16/11/2012 12:54 Daniel Braniss said the following:

 This is starting to turn into a bikeshed, but anyway...

 on 16/11/2012 12:00 Daniel Braniss said the following:
 the question as to what compiler was used to compile the kernel is a bit of 
 an
 oxymoron, since the kernel is made up of many different modules, which get 
 compiled
 either by different compilers, or different compiler flags.

 The canonical way to compile a kernel is to use buildkernel and compile 
 modules
 
 this does not guarantee uniformity, just look at the output it produces and 
 you will see
 different compilers/assemblers/scripts/flags

Different flags specified in the build infrastructure are OK.

 along with the kernel.  Other configurations are supported too, of course.

 
 since the compiler does 'sign' the modules it compiles (and clang 
 will/should
 do it soon: http://llvm.org/bugs/show_bug.cgi?id=7292) some tool like
 file(1) could be modified to provide it, or config -x (8) ...

 The key word in your note about clang is 'soon' as in 'not yet'.
 Dimitry wrote that he will handle it :-)

Right. 'will' is not 'did'.


 Besides, when I see a bug report with a dmesg *I* want to immediately know 
 what
 compiler was used there.
 today it's clang vs. gcc -- transition time --, but again it's only part of 
 the story,
 and soon it will only be noise.

Different kernel toolchains are here to stay.
And it's not just clang vs gcc, but also different toolchains for embedded
world, etc.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: compiler info in kernel identification string

[Chris Hoy Poy]

BeBei
Sent from my HTC Velocity 4G on the Next G network

- Reply message -
From: Erik Cederstrand e...@cederstrand.dk
To: Andriy Gapon a...@freebsd.org
Cc: Ian Lepore free...@damnhippie.dyndns.org, Mateusz Guzik 
mjgu...@gmail.com, Dimitry Andric d...@freebsd.org, 
freebsd-current@FreeBSD.org
Subject: compiler info in kernel identification string
Date: Fri, Nov 16, 2012 5:21 pm




Den 16/11/2012 kl. 08.34 skrev Andriy Gapon a...@freebsd.org:

 on 16/11/2012 01:09 Dimitry Andric said the following:
 And as I remarked in another reply, now that I have thought about it a
 bit, I would much rather see this information moved to a sysctl or dmesg
 line, than in uname.  With the happy side effect that no existing uname
 parsers would be confused!
 
 I would still like to have at least compiler's base name or type or 
 something
 in uname.

This has been brought up before, but what about putting all this in a separate 
file, e.g. /etc/buildinfo?

At least I'd like this to be configurable. I'm trying to get FreeBSD code in a 
shape where it can optionally produce deterministic binaries from two different 
builds (i.e. comparable with md5) as long as the binaries are functionally 
equivalent, and irrelevant info like compiler version, hostname, username, 
timestamp, absolute path etc. are a nuisance if they can't be turned off with 
-fno-ident, -frandom-seed, -DSTRIP_FBSDID, ar -D and the like.

Thanks,
Erik
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: compiler info in kernel identification string

[Dimitry Andric]

On 2012-11-16 11:00, Daniel Braniss wrote:

on 16/11/2012 11:20 Erik Cederstrand said the following:

Den 16/11/2012 kl. 08.34 skrev Andriy Gapon a...@freebsd.org:

...

hostname, username, timestamp, absolute path etc. are a nuisance if they
can't be turned off with -fno-ident, -frandom-seed, -DSTRIP_FBSDID, ar -D and
the like.

the question as to what compiler was used to compile the kernel is a bit of an
oxymoron, since the kernel is made up of many different modules, which get
compiled
either by different compilers, or different compiler flags.


Yes, but in practice this seldom happens.  In Linux they also just print
one compiler identification string at bootup, basically the compiler
which the main Makefile used.



since the compiler does 'sign' the modules it compiles (and clang will/should
do it soon: http://llvm.org/bugs/show_bug.cgi?id=7292) some tool like
file(1) could be modified to provide it, or config -x (8) ...


Well, gcc does this, and you get all the .comment sections merged into
the final kernel executable, but identifying it from there is a bit
messy.  A simple sysctl is just handier.

And regarding clang, I don't have the time to implement this very soon,
and I doubt it is very high on the bug priority list with upstream
either.  They just branched for the 3.2 release, and they are much
busier squashing bugs now. :)



IMHO, the only meaningfull information added to uname was the svn/git(and
hopefully hg) rev. version.


AFAIK newvers.sh only handles svn and git.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: compiler info in kernel identification string

[David Chisnall]

On 16 Nov 2012, at 07:41, Dimitry Andric wrote:

 And regarding clang, I don't have the time to implement this very soon,
 and I doubt it is very high on the bug priority list with upstream
 either.  They just branched for the 3.2 release, and they are much
 busier squashing bugs now. :)

Implementing this looks pretty trivial - just add a module-level inline 
assembly block into the IR for each compilation unit.  Most of the code 
required in clang will be to provide the command-line flag for turning it off.

If we want this, I probably have time to implement it next week, and we can 
pull it into the FreeBSD version of clang immediately.

David
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: compiler info in kernel identification string

[Mateusz Guzik]

On Tue, Nov 13, 2012 at 03:57:55PM -0800, David Wolfskill wrote:
 I like the idea, but I have long found the idea of putting this type of
 logic (including VCS-awareness) in newvers.sh itself something that is
 prone to turn what should be a rather simple script into a ... mess.

I don't think newvers.sh is a mess (yet) and I find current features
highly desirable.

 What I have been using for several months has been a modified newvers.sh
 that uses an externally-defined function (from a file that is sourced)
 to handle whatever VCS-specific things I think are appropriate.  (Thus,
 folks who want to use one VCS don't need to have newvers.sh test for
 VCSen they don't use; they could also provide a sample file that
 provides the function.  An installation could use a symlink to point to
 the function definition of choice  We could even have a kitchen
 sink default, that goes through all the hoops  gyrations the current
 code does, if folks want that.)

newvers.sh definitely should continue to work without hints on cvs/svn/git.

Moving checks to different files seems completely unnecessary for me as
I don't find current checks expensive. But if you do the work I see
nothing wrong with it. :) (but please note I'm in no position to accept
your changes)

Given that, low-cost support for custom version strings could look like
this: after all standard values are filled, prepare complete version
string, then source custom script if it exists.

This way your script has access to everything that newvers.sh was able to
determine and to complete version string, and you are free to change it
however you want using detected revision/compiler/whatever or completely
new data.

-- 
Mateusz Guzik mjguzik gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: compiler info in kernel identification string

[Andriy Gapon]

on 14/11/2012 01:43 Mateusz Guzik said the following:
 Hello,
 
 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

When are you committing this?

 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.



-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: compiler info in kernel identification string

[Dimitry Andric]

On 2012-11-15 21:43, Andriy Gapon wrote: on 14/11/2012 01:43 Mateusz Guzik 
said the following:

Hello,

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


When are you committing this?


Please don't commit it yet, we're not done reviewing. :)

For starters, this hardcodes the compiler names gcc and clang, and
this will include incorrect information into the kernel version string,
if you use another setting for ${CC}.

Then, if you fix the script use ${CC}, and set it to gcc versions from
ports (for example), the parsing breaks down, as I expected:

  $ echo $CC
  /usr/local/bin/gcc47
  $ compiler=gcc-`$CC --version | head -n1 | awk '{ print $3 - $4}'`
  $ echo $compiler
  gcc-Ports-Collection)

So please fix this first.  Either handle all possible variants of
version output, or just put the version string verbatim into the
identification.  I would opt for the latter.

Last but not least, I am not sure this information belongs in uname at
all.  Maybe it would be better to put it somewhere else, in a sysctl, or
show it in dmesg.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: compiler info in kernel identification string

[Dimitry Andric]

On 2012-11-14 16:38, Ian Lepore wrote:

On Wed, 2012-11-14 at 10:25 +0100, Dimitry Andric wrote:

...

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 21 | 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 can see where you're coming from, but I also think it is very fragile
to depend on parsing such information from uname.  If you do so, you
must be prepared to accept wonky input, otherwise, just don't do it. :)

And as I remarked in another reply, now that I have thought about it a
bit, I would much rather see this information moved to a sysctl or dmesg
line, than in uname.  With the happy side effect that no existing uname
parsers would be confused!
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: compiler info in kernel identification string

[Mateusz Guzik]

On Fri, Nov 16, 2012 at 12:05:33AM +0100, Dimitry Andric wrote:
 For starters, this hardcodes the compiler names gcc and clang, and
 this will include incorrect information into the kernel version string,
 if you use another setting for ${CC}.
 

Yes, I blindly assumed that both gcc and clang will keep format of --version.
For everything else you would get 'unknown-compiler'.

 
 Last but not least, I am not sure this information belongs in uname at
 all.  Maybe it would be better to put it somewhere else, in a sysctl, or
 show it in dmesg.

As stated in original mail, I don't have strong opinions on this. I only
care about accessibility of this information.

So, here is my patch that adds information at boot time and sysctl
kern.compiler:

http://people.freebsd.org/~mjg/patches/compiler-info.diff

Sample output:
Copyright (c) 1992-2012 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.0-CURRENT #281 r243095=c24a389-dirty: Fri Nov 16 00:24:46 CET 2012
f@lap:/usr/obj/i386.i386/srv/repos/freebsd/sys/DEVEL i386
Compiled with cc (GCC) 4.2.1 20070831 patched [FreeBSD] -- HERE
WARNING: WITNESS option enabled, expect reduced performance.
WARNING: DIAGNOSTIC option enabled, expect reduced performance.
CPU: Intel(R) Core(TM)2 Duo CPU P9600 @ 2.66GHz (2635.19-MHz 686-class CPU)
[..]

As you can see only first line is captured and I go with assumption that
--version works, I hope this is ok.

-- 
Mateusz Guzik mjguzik gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: compiler info in kernel identification string

[Andriy Gapon]

on 16/11/2012 01:05 Dimitry Andric said the following:
 For starters, this hardcodes the compiler names gcc and clang, and
 this will include incorrect information into the kernel version string,
 if you use another setting for ${CC}.

Oops, I agree.  The script should definitely make use of $CC.
Thank you for pointing this out.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: compiler info in kernel identification string

[Andriy Gapon]

on 16/11/2012 01:09 Dimitry Andric said the following:
 And as I remarked in another reply, now that I have thought about it a
 bit, I would much rather see this information moved to a sysctl or dmesg
 line, than in uname.  With the happy side effect that no existing uname
 parsers would be confused!

I would still like to have at least compiler's base name or type or something
in uname.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: compiler info in kernel identification string

[Dimitry Andric]

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 21 | 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 (mockbu...@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 21 | 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.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: compiler info in kernel identification string

[Dimitry Andric]

On 2012-11-14 08:01, Daniel Braniss wrote:

in the old days (I'm talking before C :-) I remmeber one compiler
putting such info in the code it produced, I wonder if that's the case
with gcc/clang, and if so it would be nice if file(1) could show it.
my 3c,


As far as I know, gcc has always included such information:

  $ touch empty.c
  $ gcc -c empty.c
  $ objdump -j .comment -s empty.o

  empty.o: file format elf32-i386-freebsd

  Contents of section .comment:
    00474343 3a202847 4e552920 342e322e  .GCC: (GNU) 4.2.
   0010 31203230 30373038 33312070 61746368  1 20070831 patch
   0020 6564205b 46726565 4253445d 00ed [FreeBSD].
  $ gcc47 -c empty.c
  $ objdump -j .comment -s empty.o

  empty.o: file format elf32-i386-freebsd

  Contents of section .comment:
    00474343 3a202846 72656542 53442050  .GCC: (FreeBSD P
   0010 6f727473 20436f6c 6c656374 696f6e29  orts Collection)
   0020 20342e37 2e332032 30313230 39323920   4.7.3 20120929
   0030 28707265 72656c65 61736529 00(prerelease).

There is an old LLVM PR to get the same supported for clang, but it
ended up at the bottom of the pile:

  http://llvm.org/bugs/show_bug.cgi?id=7292

I should probably just make a patch for it, and submit it. :-)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: compiler info in kernel identification string

[Ian Lepore]

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 21 | 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 
 (mockbu...@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 21 | 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


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

compiler info in kernel identification string

[Mateusz Guzik]

Hello,

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.

Comments?

-- 
Mateusz Guzik mjguzik gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: compiler info in kernel identification string

[David Wolfskill]

On Wed, Nov 14, 2012 at 12:43:03AM +0100, Mateusz Guzik wrote:
 Hello,
 
 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
 ... 
 I have no strong opinions on format, I just want this information easly
 accessible.
 
 Comments?
 

I like the idea, but I have long found the idea of putting this type of
logic (including VCS-awareness) in newvers.sh itself something that is
prone to turn what should be a rather simple script into a ... mess.

What I have been using for several months has been a modified newvers.sh
that uses an externally-defined function (from a file that is sourced)
to handle whatever VCS-specific things I think are appropriate.  (Thus,
folks who want to use one VCS don't need to have newvers.sh test for
VCSen they don't use; they could also provide a sample file that
provides the function.  An installation could use a symlink to point to
the function definition of choice  We could even have a kitchen
sink default, that goes through all the hoops  gyrations the current
code does, if folks want that.)

Extending that to define a function for compiler-awareness should be
straightforward -- and (IMO) avoid cluttering newvers.sh even more.

Caveat: I'm not a committer.  I do exercise newvers.sh a bit more than
many folks, though.  :-}

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Taliban: Evil men with guns afraid of truth from a 14-year old girl.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgp48A8IVJCso.pgp
Description: PGP signature

Re: compiler info in kernel identification string

[Erich Dollansky]

Hi,

On Wed, 14 Nov 2012 00:43:03 +0100
Mateusz Guzik mjgu...@gmail.com wrote:

 Hello,
 
 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.
 
 Comments?
 

this is a good idea!

Erich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: compiler info in kernel identification string

[Jov]

good idea.
show version cmd in postgresql prints os version,compiler info etc. useful
for problem report.

jov
在 2012-11-14 上午7:43，Mateusz Guzik mjgu...@gmail.com写道：

 Hello,

 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.

 Comments?

 --
 Mateusz Guzik mjguzik gmail.com
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: compiler info in kernel identification string

[Daniel Braniss]

 Hello,
 
 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.
 
 Comments?

in the old days (I'm talking before C :-) I remmeber one compiler
putting such info in the code it produced, I wonder if that's the case
with gcc/clang, and if so it would be nice if file(1) could show it.
my 3c,
danny



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org