From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20850 invoked by alias); 29 Dec 2008 20:23:42 -0000 Received: (qmail 20766 invoked by uid 22791); 29 Dec 2008 20:23:40 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=BAYES_00,J_CHICKENPOX_75 X-Spam-Check-By: sourceware.org Received: from mxout.hispeed.ch (HELO smtp.hispeed.ch) (62.2.95.247) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 29 Dec 2008 20:22:39 +0000 Received: from teraflex-bp.dyndns.org (84-73-59-216.dclient.hispeed.ch [84.73.59.216]) (authenticated bits=0) by smtp.hispeed.ch (8.12.11.20060308/8.12.11/taifun-1.0) with ESMTP id mBTKMaX8017821 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 29 Dec 2008 21:22:36 +0100 Received: from localhost (localhost [[UNIX: localhost]]) by teraflex-bp.dyndns.org (8.14.3/8.12.10/SuSE Linux 0.7) id mBTKMWLU028518; Mon, 29 Dec 2008 15:22:32 -0500 From: "Brian O'Mahoney" To: gcc@gcc.gnu.org Subject: gcc and the kernel Date: Mon, 29 Dec 2008 20:38:00 -0000 User-Agent: KMail/1.9.9 CC: opensuse@opensuse.org, gcc-help@gcc.gnu.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <200812291522.31842.omb@bluewin.ch> X-Original-From: "Brian O'Mahoney" X-Md5-Body: 18ce31e2c1058c61e4cf504132015700 X-Message-Uid: 0016368be8ef292100000002000000004959318b000000000000000000000616 X-Transmit-Date: Monday, 29 Dec 2008 15:22:35 -0500 X-Teraflex: 10; Monday, 29 Dec 2008 15:22:35 -0500 Replyto: omb@bluewin.ch X-Sender-Postmaster: Postmaster@teraflex-bp.dyndns.org Read-Receipt-To: omb@bluewin.ch Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2008-12/txt/msg00283.txt.bz2 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