[LLVMdev] Linux Kernel Compile for Sparc v8 Arch
Keun Soo Yim
yim6 at illinois.edu
Sat Oct 4 20:26:53 PDT 2008
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
> register struct thread_info *current_thread_info_reg asm("g6");
> Error Message:
> include/asm/thread_info.h:77: error: invalid register name for
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
The Sparc backend has no active maintainer . 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.
 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,
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.
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 \
/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: *** [crtbegin.o] Error 1
make: Leaving directory
(2) If I runaround (1), there comes another error!
arc-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/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: *** [libgcc/./_mulvsi3.o] Error 1
make: Leaving directory
- Keun Soo
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev