Compiling linux kernel 2.6.5 with icc

Compiling linux kernel 2.6.5 with icc

Hi,
recently I've found a script on the kernel list posted by Jun Nakajima from Intel.
It's called kicc and it should compile the kernel with icc instead of gcc.
(http://marc.theaimsgroup.com/?l=linux-kernel&m=107913092300497&w=2)
In the message on lkml it says that no patches are needed for a kernel build.
Unfortunately the compilation process always stops with the following error message:
arch/i386/kernel/cpu/mtrr/if.c(164): error: expression must have a constant value
case MTRRIOC_ADD_ENTRY:
(...)
Any hints?
Thanks in advance.

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hi,

I got the same script and you're right: it doesn't work properly. I think that it was designed for the Linux Compiler 7 for Linux. See item 2b) below, it fixes ONE problem of icc/linux.

I just finished a new kernel patch for Linux 2.6.5 and Intel C/C++ Compiler for Linux 8.0.055. It will be published on my free software site www.pyrillion.org in the near future (it is currently bound to a publication in the German Linux Magazine, sorry!).

But I can give you some valuable information about Linux kernel building with icc 8.0.055 and kernel 2.6.x versions. You have to solve several problems:

1.) Convert the command line switches, which are incompatible to the GCC switches. This applies to e.g. "-fp" (equals to -fno-omit-frame-pointer), "-Os" (equals to -O1), and so on. You can do that in a script or in a C program as I did it. The big problem here is the GCC switch "-fno-common", which is also implemented by ICC but in a different way! The switch should automatically convert common symbols (the Linux kernel DOES rely on it), initialize and move them to the .bss ELF section. Unfortunately, ICC always emits common symbols. This problem disallow the loading of kernel modules because the kernel loader checks for common symbols in the module binary. I fixed the problem by first compiling a C source to assembler source, patching the assembler source (thus removing the common symbols) and finally compiling the assembler source to object code. To make a long story short, there are some more things to change here.

2.) You HAVE TO patch at least the three following things:

2a) include/asm-i386/byteorder.h: patch the inline assembly of the byteswap functions and use the intrinsic _bswap. If you don't do this, then your compiler will come up with internal compiler errors 0_(4900+5) if IPO is enabled.

2b) include/asm-i386/ioctl.h: patch the macro _IOC_TYPECHECK

2c) arch/i386/lib/memcpy.c: include a body for the function "memcmp" (otherwise not found in the link stage).

3.) More problems:

3a) The biggest problem of icc 8.0.055 is "inline assembly". The compiler emits wrong code under certain conditions, which I did not analyse. I just patched various sources. For instance, the function "atomic_dec_and_lock" in arch/i386/lib/dec_and_lock.c is compiled in a wrong way and yields to wrong code, which is not SMP-safe. icc emits code, which operates on local stack copies of the inline assembly parameters (the asm constrains in the source are right!). I just created a completely new version of this function in pure assembler.

3b) inline functions: icc does not honor the attribute "always_inline" but inlines functions on behalf of the IPO mechanism. In my point of view, this was a very bad design decision. A lot of the bitmap manipulation functions (also inline assembly, no compiler intrinsics available) are not expanded inline and are emitted as static functions, i.e.: an inline function with one assembler instruction yields to a separate function with prologue, epilogue, call overhead and stack cleanup. That can't be right... If you convert these functions to C macros to force the Intel Compiler to inline them, then it produces in certain situations wrong code. Gotcha!

By the way: The Intel Compiler for Linux only supersedes GNU gcc 3.3.3 if you use PGO (profile guided optimization) instrumentation in the
kernel. I checked this with my own kernel module, which will be part of the above mentioned kernel patch.

Rgs, Ingo.

Hi Ingo,

Thanks for the generous explanations.
I'm looking forward to your kernel patch release.
Could you point me to the relevant 'Linux Magazin' issue?

Gru, Markus

Message Edited by trippels on 04-21-2004 09:45 PM

does the kicc script work with Intel Compiler 8.0 or does it only work with 7.0?

Hi,

the script works fine with both compilers 7.x and 8.0. The problem is that you can't compile a 2.6. kernel without patching it.

Rgs, Ingo.

Hi,

the current issue 06/04 of the German Linux Magazine contains a preview. Thus, the Linux kernel publication will be in issue 07/04.

Furthermore, I finished two updates of the kernel patch (current version 0.8 available at http://www.pyrillion.org/linuxkernelpatch.html). I will publish versions 0.9 (discussed in the publication) andthe new 1.0 in June '04. Because of the Linux Magazine publication, I can't publish them now for legal reasons. Sorry.

Especially version 1.0 offers a variety of new patches. You can choose to apply a 'minimal patch' to the 2.6 kernelor to use the 'best patch' proven to perform 'best'. Last but not least, there are some experimental patches available as well. The new patches are less invasive and offer a better kernel PGO support.

Rgs, Ingo.

Leave a Comment

Please sign in to add a comment. Not a member? Join today