[LLVMdev] compile linux kernel

Ashish Bijlani ashish.bijlani at gmail.com
Sat Sep 27 18:08:44 PDT 2008


Thanks. I actually checked the IR code generated, it seems inline
assembly is being handled correctly. The preprocessing is also being
done correctly. Here is the asm-offsets.i file snippet..

...
builtin_offsetof(struct crypto_tfm,__crt_ctx)));
 asm volatile("\n->" : : );
 asm volatile("\n->" "__NR_syscall_max" " %0 " "sizeof(syscalls) - 1"
: : "i" (sizeof(syscalls) - 1));
 return 0;
}
....

and here is the IR code snippet -

...
    tail call void asm sideeffect "\0A->__NR_syscall_max $0
sizeof(syscalls) - 1", "i,~{dirflag},~{fpsr},~{flags}"( i64 285 )
nounwind
    ret i32 0
}
....

However, the build system is trying to generate asm-offset.s from
asm-offset.c and then it populates asm-offsets.h header file for
correct values. Here is the code from Kbuild -

"define cmd_offsets
    (set -e; \
     echo "#ifndef __ASM_OFFSETS_H__"; \
     echo "#define __ASM_OFFSETS_H__"; \
     echo "/*"; \
     echo " * DO NOT MODIFY."; \
     echo " *"; \
     echo " * This file was generated by Kbuild"; \
     echo " *"; \
     echo " */"; \
     echo ""; \
     sed -ne $(sed-y) $<; \
     echo ""; \
     echo "#endif" ) > $@
endef
"
Since this does "sed" on asm-offsets.s file and retrieves the offsets
of the symbols, it fails when it gets LLVM generated "asm-offsets.s"
IR file. As a result the asm-offsets.h file generated is empty and
doesn't contain the symbol __NR_SYSCALLS_max.

If I use GCC to generate asm-offsets.s file, then the build system go
ahead but fails when it generates .so files as Andrew pointed out.

...
llvm-gcc -m elf_x86_64 -nostdlib -fPIC -shared
-Wl,-soname=linux-vdso.so.1  -Wl,--hash-style=sysv
-Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096
-Wl,-T,arch/x86_64/vdso/vdso.lds arch/x86_64/vdso/vdso-start.o
arch/x86_64/vdso/vdso-note.o arch/x86_64/vdso/vclock_gettime.o
arch/x86_64/vdso/vgetcpu.o arch/x86_64/vdso/vvar.o -o
arch/x86_64/vdso/vdso.so
arch/x86_64/vdso/vvar.o: file not recognized: File format not recognized
collect2: ld returned 1 exit status
....

Now, If the build systems generates .so files, then it will be
difficult o actually generate fully arch-independent kernel code,
isn't it?

thanks,
ashish
On Sat, Sep 27, 2008 at 8:16 PM, Dale Johannesen <dalej at apple.com> wrote:
>
> On Sep 27, 2008, at 4:34 PM, Ashish Bijlani wrote:
>
>> Thanks for the help. I've a couple of questions though:
>>
>> How does LLVM deal with inline assembly?
>
> It's been implemented piece by piece on an as-needed basis.  At this
> point most of the things people actually use should work.   llvm-gcc
> has seen the Linux kernel, so most usages in there ought to work.
>
> The symptoms here look more like a preprocessor problem than an asm
> problem.  Your asm snippet works fine with llvm's top of tree, and I
> suspect the real problem is something else.  If you compile with -save-
> temps what does the .i file look like?
>
>> I'm trying to compile kernel and I get this error probably because
>> LLVM is not able to handle inline assembly. I'm using LLVM-2.3
>>
>> code snippet from "arch/x86_64/kernel/asm-offsets.c"
>> ....
>>
>> #define DEFINE(sym, val) \
>>        asm volatile("\n->" #sym " %0 " #val : : "i" (val))
>> ....
>>
>>    DEFINE(__NR_syscall_max, sizeof(syscalls) - 1);
>>    return 0;
>>
>> # make CROSS_COMPILE=llvm- V=1
>>
>>  llvm-gcc -Wp,-MD,arch/x86_64/kernel/.syscall.o.d  -nostdinc -isystem
>> /home/ashish/llvm/llvm-gcc4.2-2.3.source/obj/../install/lib/gcc/
>> x86_64-unknown-linux-gnu/4.2.1/include
>> -D__KERNEL__ -Iinclude  -include include/linux/autoconf.h -emit-llvm
>> -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
>> -fno-common -Werror-implicit-function-declaration -O2  -mtune=generic
>> -m64 -mno-red-zone -mcmodel=kernel -pipe -Wno-sign-compare
>> -fno-asynchronous-unwind-tables -funit-at-a-time -mno-sse -mno-mmx
>> -mno-sse2 -mno-3dnow -maccumulate-outgoing-args
>> -fomit-frame-pointer -g  -fno-stack-protector
>> -Wdeclaration-after-statement -Wno-pointer-sign
>> -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(syscall)"
>> -D"KBUILD_MODNAME=KBUILD_STR(syscall)" -c -o
>> arch/x86_64/kernel/.tmp_syscall.o arch/x86_64/kernel/syscall.c
>> arch/x86_64/kernel/syscall.c:22: error: '__NR_syscall_max' undeclared
>> here (not in a function)
>> arch/x86_64/kernel/syscall.c:24: error: array index in initializer not
>> of integer type
>> arch/x86_64/kernel/syscall.c:24: error: (near initialization for
>> 'sys_call_table')
>> In file included from arch/x86_64/kernel/syscall.c:25:
>> include/asm-x86_64/unistd.h:16: error: array index in non-array
>> initializer
>> include/asm-x86_64/unistd.h:16: error: (near initialization for
>> 'sys_call_table')
>> include/asm-x86_64/unistd.h:18: error: array index in non-array
>> initializer
>>
>> Note that I use "-emit-llvm" option with llvm-gcc. Is this correct of
>> am I missing something?
>> How can I fix this error?
>>
>> Thanks,
>> Ashish
>>
>> On Sat, Sep 27, 2008 at 7:03 PM, Andrew Lenharth
>> <andrewl at lenharth.org> wrote:
>>> On Fri, Sep 26, 2008 at 9:19 PM, Ashish Bijlani
>>> <ashish.bijlani at gmail.com> wrote:
>>>> Hi,
>>>>
>>>> I'm trying to compile linux-2.6.23.16 with llvm-2.3. Is it at all
>>>> possible?
>>>
>>> Yes, but it requires significant hacking, and the result for 2.6 is a
>>> mostly bitcode kernel with a few userspace shared libraries linked in
>>> as objcode (yes, the kernel builds .so files and includes them in the
>>> binary).  There are a few changes here and there you can make to the
>>> kernel code to produce significantly nicer bitcodes too (e.g. rather
>>> than having module level asm  that makes symbols weak, you can just
>>> have gcc do it).
>>>
>>> The modification to the make system is not difficult, but it requires
>>> some work and an understanding of the kernel build system.
>>>
>>> Andrew
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



More information about the llvm-dev mailing list