Thanks for the help. I've a couple of questions though:
How does LLVM deal with inline assembly?
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
>
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
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
>