[LLVMdev] Linux Kernel Compile for Sparc v8 Arch
Keun Soo Yim
Does anyone succeed at compiling Linux kernel for Sparc v8 architecture?
I am currently trying to expand the regime of LLVM to Sparc kernel codes.
The following is the initial error messages. Any comment is welcomed.
#1. Inline Assembly
Code:
register struct thread_info *current_thread_info_reg asm("g6");
Error Message:
include/asm/thread_info.h:77: error: invalid register name for 'current_thread_info_reg'
#2. Link error for single C file
Error Message:
/tmp/ccQBRbb6.s:2226: Error: symbol `lstat64' is already defined
/tmp/ccQBRbb6.s:2242: Error: symbol `stat64' is already defined
/tmp/ccQBRbb6.s:2280: Error: symbol `fstat64' is already defined
Keun Soo Yim
Török Edwin
>
>
>
> Does anyone succeed at compiling Linux kernel for Sparc v8 architecture?
>
> I am currently trying to expand the regime of LLVM to Sparc kernel
> codes.
>
> The following is the initial error messages. Any comment is welcomed.
>
>
>
> #1. Inline Assembly
>
>
>
> Code:
>
> register struct thread_info *current_thread_info_reg asm("g6");
>
>
>
> Error Message:
>
> include/asm/thread_info.h:77: error: invalid register name for
> 'current_thread_info_reg'
>
I suggest you open a bug and attach a preprocessed C source file.
>
>
> #2. Link error for single C file
>
>
>
> Error Message:
>
> /tmp/ccQBRbb6.s:2226: Error: symbol `lstat64' is already defined
>
> /tmp/ccQBRbb6.s:2242: Error: symbol `stat64' is already defined
>
> /tmp/ccQBRbb6.s:2280: Error: symbol `fstat64' is already defined
>
How does that file look like? Use -save-temps and attach them to a
bugreport.
Best regards,
--Edwin
>
>
_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Chris Lattner
Does anyone succeed at compiling Linux kernel for Sparc v8 architecture?I am currently trying to expand the regime of LLVM to Sparc kernel codes.The following is the initial error messages. Any comment is welcomed.#1. Inline Assembly
Keun Soo Yim
On 2008-09-29 07:46, Keun Soo Yim wrote:
> Does anyone succeed at compiling Linux kernel for Sparc v8 architecture?
> I am currently trying to expand the regime of LLVM to Sparc kernel codes.
> The following is the initial error messages. Any comment is welcomed.
>
> #1. Inline Assembly
>
>
>
> Code:
>
> register struct thread_info *current_thread_info_reg asm("g6");
>
>
>
> Error Message:
>
> include/asm/thread_info.h:77: error: invalid register name for
> 'current_thread_info_reg'
>
I suggest you open a bug and attach a preprocessed C source file.
>
>
> #2. Link error for single C file
>
>
>
> Error Message:
>
> /tmp/ccQBRbb6.s:2226: Error: symbol `lstat64' is already defined
>
> /tmp/ccQBRbb6.s:2242: Error: symbol `stat64' is already defined
>
> /tmp/ccQBRbb6.s:2280: Error: symbol `fstat64' is already defined
>
How does that file look like? Use -save-temps and attach them to a bugreport.
Best regards,
--Edwin
>
The Sparc backend has no active maintainer [1]. This unfortunately means that if you want bugs fixed, you will have to make the patches yourself. If this is a problem, you might want to pick a different solution for whatever project you're tackling.
-Chris
[1] Actually that's not true. I'm the maintainer and I'm active, I just don't have a sparc machine or time to care about sparc.
---
Thanks Edwin and Chris for interests!
Now, at least GCC front-end for Sparc has a problem at compilation. Chris, is there any document describing the process of porting GCC front-end to LLVM or would you like to explain a bit so that anyone interested in can port GCC front-end for Sparc and Power architecture to LLVM? It will make LLVM keep its initial status as until its version 1.6, it supported Sparc and Power front-ends.
This is a description of current Sparc front-end. The first error that I had was caused by the LLVM’s GCC front-end for x86. As the front-end I used was compiled for x86 target, it cannot translate the inline assembly code into the LLVM byte code. I tried to compile both original GCC 4.2 and the GCC front-end for LLVM however both had at least one error. The GCC 4.2 for Sparc, MIPS, and ARM is currently broken (see, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32101).
Edwin, new errors are attached below as I identified the reason of the previously posted errors. First bug I previously posted was due to inline assembly and the second bug is due to the difference in linker option which I solved by changing the option.
(1) An error message generated when compile GCC for Sparc architecture.
/home/ksyim/workspace/compiler/llvm/gcc-4.2.2/objdir-sparc/./gcc/xgcc -B/home/ksyim/workspace/compiler/llvm/gcc-4.2.2/objdir-sparc/./gcc/ -B/home/ksyim/workspace/compiler/llvm/gcc-4.2.2/release-sparc/sparc-sun-linux/bin/ -B/home/ksyim/workspace/compiler/llvm/gcc-4.2.2/release-sparc/sparc-sun-linux/lib/ -isystem /home/ksyim/workspace/compiler/llvm/gcc-4.2.2/release-sparc/sparc-sun-linux/include -isystem /home/ksyim/workspace/compiler/llvm/gcc-4.2.2/release-sparc/sparc-sun-linux/sys-include -O2 -O2 -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../libdecnumber -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -Dinhibit_libc \
-c ../../gcc/crtstuff.c -DCRT_BEGIN \
-o crtbegin.o
/home/ksyim/workspace/compiler/llvm/gcc-4.2.2/objdir-sparc/./gcc/as: line 2: exec: -Q: invalid option
exec: usage: exec [-cl] [-a name] file [redirection ...]
make[2]: *** [crtbegin.o] Error 1
make[2]: Leaving directory `/scr/ksyim/workspace/compiler/llvm/gcc-4.2.2/objdir-sparc/gcc'
(2) If I runaround (1), there comes another error!
/scr/ksyim/workspace/compiler/llvm/llvm-gcc4.2-2.3.source/objdir-sparc/./gcc/xgcc -B/scr/ksyim/workspace/compiler/llvm/llvm-gcc4.2-2.3.source/objdir-sparc/./gcc/ -B/home/ksyim/workspace/compiler/llvm/llvm-gcc4.2-2.3.source/release-sparc//sparc-sun-linux/bin/ -B/home/ksyim/workspace/compiler/llvm/llvm-gcc4.2-2.3.source/release-sparc//sparc-sun-linux/lib/ -isystem /home/ksyim/workspace/compiler/llvm/llvm-gcc4.2-2.3.source/release-sparc//sparc-sun-linux/include -isystem /home/ksyim/workspace/compiler/llvm/llvm-gcc4.2-2.3.source/release-sparc//sparc-sun-linux/sys-include -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../libdecnumber -I/home/ksyim/workspace/compiler/llvm/llvm-2.3/objdir-sparc//include -I/scr/ksyim/workspace/compiler/llvm/llvm-2.3/include -DL_mulvsi3 -c ../../gcc/libgcc2.c -o libgcc/./_mulvsi3.o
Cannot yet select: 0x8a92348: i32,i32 = smul_lohi 0x8aa5150, 0x8a925f8
../../gcc/libgcc2.c:177: internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://developer.apple.com/bugreporter> for instructions.
make[3]: *** [libgcc/./_mulvsi3.o] Error 1
make[3]: Leaving directory `/scr/ksyim/workspace/compiler/llvm/llvm-gcc4.2-2.3.source/objdir-sparc/gcc'
- Keun Soo
Török Edwin
>
> Thanks Edwin and Chris for interests!
>
>
>
>
>
> Now, at least GCC front-end for Sparc has a problem at compilation.
> Chris, is there any document describing the process of porting GCC
> front-end to LLVM or would you like to explain a bit so that anyone
> interested in can port GCC front-end for Sparc and Power architecture
> to LLVM? It will make LLVM keep its initial status as until its
> version 1.6, it supported Sparc and Power front-ends.
>
>
>
> This is a description of current Sparc front-end. The first error that
> I had was caused by the LLVM’s GCC front-end for x86. As the front-end
> I used was compiled for x86 target,
>
If you want to build a cross-compiler, then --target must be the arch
you want to generate code for (sparc in this case), and --build and
--host must be the host you are building the compiler on (x86 for you).
> it cannot translate the inline assembly code into the LLVM byte code.
> I tried to compile both original GCC 4.2 and the GCC front-end for
> LLVM however both had at least one error. The GCC 4.2 for Sparc, MIPS,
> and ARM is currently broken (see,
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32101).
>
So you're trying to build a cross-compiler, right?
I have a cross-compiler package from emdebian.org, so it should be
possible to build one (though I haven't tried to build one manually
neither for upstream gcc, nor for llvm-gcc):
$ sparc-linux-gnu-gcc -v
Using built-in specs.
Target: sparc-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,obj-c++
--prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/sparc-linux-gnu/include/c++/4.2.4
--program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug
--with-cpu=v8 --with-long-double-128 --enable-checking=release
--program-prefix=sparc-linux-gnu-
--includedir=/usr/sparc-linux-gnu/include --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=sparc-linux-gnu
Thread model: posix
gcc version 4.2.4 (Debian 4.2.4-3)
Of course you'll also need a sparc binutils:
$ sparc-linux-gnu-as --version
GNU assembler (GNU Binutils) 2.18.0.20080103
Copyright 2007 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `sparc-linux-gnu'.
Does --disable-multilib, or --with-cpu=v8 help?
I think you can try by marking SMUL_LOHI as Expand, similar to how
UMUL_LOHI is marked in SparcISelLowering.cpp:
// FIXME: Sparc provides these multiplies, but we don't have them yet.
setOperationAction(ISD::UMUL_LOHI, MVT::i32, Expand);
setOperationAction(ISD::SMUL_LOHI, MVT::i32, Expand);
Or implement SMUL_LOHI ;)