gcc and the kernel

gcc and the kernel

[Brian O'Mahoney]

OK, there are a few more things to say about gcc, and the kernel, and 
distributions (also the way patches to both work, to both).

Stipulations: (a) I always try to run the current stable kernel, released by
the 'stable-team' led by GKH. But he is getting too good, stable is
2.6.27.10 but I am running 2.6.27.7 and 2.6.28 is too bleeding edge.
(b) I am running a very heavily patched SuSE 11.0 but I have the 'SuSE
build factory' in my Yast list so for lots of things I am actually executing
SuSE 11.2 alpha code. My system gcc is:

gcc -v
Using built-in specs.
Target: x86_64-suse-linux
Configured 
with: ../configure --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE 
Linux' --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --program-suffix=-4.3 --enable-version-specific-runtime-libs --enable-linux-futex --without-system-libunwind --with-cpu=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.3.2 20080715 (prerelease) [gcc-4_3-branch revision 137837]
 (SUSE Linux)

ie not to shabby, but __NOT__ too new either, and note it is a SuSE special: 
4.3.2 20080715 (prerelease) [gcc-4_3-branch revision 137837], and you would
need to look at the (s)rpm in the 11.0 source repository to see what they
changed, ... but also see below.

But I happen, right now, to need the VERY latest gcc, 
so /opt/gcc-4.4-20081219/bin/gcc is a recent snapshot and I can select it
either in my PATH or with 'export GCC=/opt/gcc-4.4-20081219/bin/gcc' etc

SO

(1) The kernel dosn't use the latest gcc, and even quite old gcc's compile the 
kernel

(2) Kernel space code is not the same, ie the same (binary)API as user space 
and gets interrupts, so some user space optimizations are always turned off 
in the kernel, grep lkml/google for Tovolds+alias to read an old flame-war.

(3) if a gcc compiles 2.6.x it will normally compile 2.6.x.y ie the patch 
releases.

(4) I think there is someone on the Debian integration team who tries to build 
the latest kernels with the latest gcc, he finds lots of problems and submits 
bugs to both camps. I dont envy him.

Last, a word to the wise, compiler developers, are by nature fairly agressive 
but, unless you want to work on gcc itself, it is wise to stay a bit behind 
the bleeding edge, and, unless your systems are excellently backed up,
___DONT_BUILD_THE_KERNEL___ with and untested gcc. I mean a kernel you are 
going to try to run. For an example of why not see the 'ix68 string 
direction' fiasco noting that an interrupt can happen anywhere and that the 
CPU x flag is a non-deterministic (to the interrupt code) part of the 
interrupted context. Oh what fun!

[snip from LWN.NET]

"Since version 4.3, gcc changed its behaviour concerning the x86/x86-64 
ABI and the direction flag, that is it now assumes that the direction 
flag is cleared at the entry of a function and it doesn't clear once 
more if needed.

This causes some problems with the Linux kernel which does not clear
the direction flag when entering a signal handler. The small code below
(for x86-64) demonstrates that. ..." If you dont know see www.lwn.net.

-- 
Greetings, Brian

Re: gcc and the kernel

[Steven Bosscher]

On Mon, Dec 29, 2008 at 9:22 PM, Brian O'Mahoney <omb@bluewin.ch> wrote:
> OK, there are a few more things to say about gcc, and the kernel, and
> distributions (also the way patches to both work, to both).
>
> Stipulations: (a) I always try to run the current stable kernel, released by
> the 'stable-team' led by GKH. But he is getting too good, stable is
> 2.6.27.10 but I am running 2.6.27.7 and 2.6.28 is too bleeding edge.
> (b) I am running a very heavily patched SuSE 11.0 but I have the 'SuSE
> build factory' in my Yast list so for lots of things I am actually executing
> SuSE 11.2 alpha code. My system gcc is:
>
> gcc -v
> Using built-in specs.
> Target: x86_64-suse-linux
> Configured
> with: ../configure --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE
> Linux' --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --program-suffix=-4.3 --enable-version-specific-runtime-libs --enable-linux-futex --without-system-libunwind --with-cpu=generic --build=x86_64-suse-linux
> Thread model: posix
> gcc version 4.3.2 20080715 (prerelease) [gcc-4_3-branch revision 137837]
>  (SUSE Linux)
>
> ie not to shabby, but __NOT__ too new either, and note it is a SuSE special:
> 4.3.2 20080715 (prerelease) [gcc-4_3-branch revision 137837], and you would
> need to look at the (s)rpm in the 11.0 source repository to see what they
> changed, ... but also see below.
>
> But I happen, right now, to need the VERY latest gcc,
> so /opt/gcc-4.4-20081219/bin/gcc is a recent snapshot and I can select it
> either in my PATH or with 'export GCC=/opt/gcc-4.4-20081219/bin/gcc' etc
>
> SO
>
> (1) The kernel dosn't use the latest gcc, and even quite old gcc's compile the
> kernel
>
> (2) Kernel space code is not the same, ie the same (binary)API as user space
> and gets interrupts, so some user space optimizations are always turned off
> in the kernel, grep lkml/google for Tovolds+alias to read an old flame-war.
>
> (3) if a gcc compiles 2.6.x it will normally compile 2.6.x.y ie the patch
> releases.
>
> (4) I think there is someone on the Debian integration team who tries to build
> the latest kernels with the latest gcc, he finds lots of problems and submits
> bugs to both camps. I dont envy him.
>
> Last, a word to the wise, compiler developers, are by nature fairly agressive
> but, unless you want to work on gcc itself, it is wise to stay a bit behind
> the bleeding edge, and, unless your systems are excellently backed up,
> ___DONT_BUILD_THE_KERNEL___ with and untested gcc. I mean a kernel you are
> going to try to run. For an example of why not see the 'ix68 string
> direction' fiasco noting that an interrupt can happen anywhere and that the
> CPU x flag is a non-deterministic (to the interrupt code) part of the
> interrupted context. Oh what fun!
>
> [snip from LWN.NET]
>
> "Since version 4.3, gcc changed its behaviour concerning the x86/x86-64
> ABI and the direction flag, that is it now assumes that the direction
> flag is cleared at the entry of a function and it doesn't clear once
> more if needed.
>
> This causes some problems with the Linux kernel which does not clear
> the direction flag when entering a signal handler. The small code below
> (for x86-64) demonstrates that. ..." If you dont know see www.lwn.net.
>
> --
> Greetings, Brian
>

So, after all these words (congrats on your nice system), what did you
want to say?

Gr.
Steven

Re: gcc and the kernel

[Andi Kleen]

"Brian O'Mahoney" <omb@bluewin.ch> writes:
>
> Last, a word to the wise, compiler developers, are by nature fairly agressive 
> but, unless you want to work on gcc itself, it is wise to stay a bit behind 
> the bleeding edge, and, unless your systems are excellently backed up,
> ___DONT_BUILD_THE_KERNEL___ with and untested gcc. I mean a kernel you are 
> going to try to run. For an example of why not see the 'ix68 string 
> direction' fiasco noting that an interrupt can happen anywhere and that the 
> CPU x flag is a non-deterministic (to the interrupt code) part of the 
> interrupted context. Oh what fun!

This particular problem has nothing to do with the compiler that built the
kernel.

-Andi
-- 
ak@linux.intel.com

Re: gcc and the kernel

[Andrew Haley]

Brian O'Mahoney wrote:

Please don't cross-post to gcc- and gcc-help

> "Since version 4.3, gcc changed its behaviour concerning the x86/x86-64 
> ABI and the direction flag, that is it now assumes that the direction 
> flag is cleared at the entry of a function and it doesn't clear once 
> more if needed.
> 
> This causes some problems with the Linux kernel which does not clear
> the direction flag when entering a signal handler. The small code below
> (for x86-64) demonstrates that. ..." If you dont know see www.lwn.net.

Just to save everyone's time: this kernel bug is long (well, since March)
fixed.

Andrew.