On Mon, Dec 29, 2008 at 9:22 PM, Brian O'Mahoney <omb@xxxxxxxxxx> 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
