llvm-gcc and mips

I tried to cross-compile llvm-gcc for mips, but it crashes somewhere
in the build process:

/home/kevin/Documents/School/2eLIC/Thesis/work/build/llvmgcc-mips/./gcc/xgcc
-B/home/kevin/Documents/School/2eLIC/Thesis/work/build/llvmgcc-mips/./gcc/
-B/home/kevin/Documents/School/2eLIC/Thesis/work/build/llvmgcc-mips/../../install/llvmgcc-mips/mips-unknown-linux-gnu/bin/
-B/home/kevin/Documents/School/2eLIC/Thesis/work/build/llvmgcc-mips/../../install/llvmgcc-mips/mips-unknown-linux-gnu/lib/
-isystem /home/kevin/Documents/School/2eLIC/Thesis/work/build/llvmgcc-mips/../../install/llvmgcc-mips/mips-unknown-linux-gnu/include
-isystem /home/kevin/Documents/School/2eLIC/Thesis/work/build/llvmgcc-mips/../../install/llvmgcc-mips/mips-unknown-linux-gnu/sys-include
-O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -I. -I.
-I../../../llvm-gcc4.2-2.2/gcc -I../../../llvm-gcc4.2-2.2/gcc/.
-I../../../llvm-gcc4.2-2.2/gcc/../include
-I../../../llvm-gcc4.2-2.2/gcc/../libcpp/include
-I../../../llvm-gcc4.2-2.2/gcc/../libdecnumber -I../libdecnumber
-I/home/kevin/Documents/School/2eLIC/Thesis/work/build/llvm-2.2/include
-I/home/kevin/Documents/School/2eLIC/Thesis/work/build/llvmgcc-mips/../llvm-2.2/include
-g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions
-fno-zero-initialized-in-bss -fno-toplevel-reorder -Dinhibit_libc \
          -c ../../../llvm-gcc4.2-2.2/gcc/crtstuff.c -DCRT_BEGIN \
          -o crtbegin.o
terminate called after throwing an instance of 'std::bad_alloc'
  what(): St9bad_alloc
../../../llvm-gcc4.2-2.2/gcc/crtstuff.c:378: internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://developer.apple.com/bugreporter&gt; for instructions.
make[2]: *** [crtbegin.o] Error 1

I had to make this change for mips to be accepted:

Index: ../../llvm-gcc4.2-2.2/gcc/Makefile.in

make -k install will install a mips cross compiler for you, I believe.

If you don't want to install it, you can run it as cd gcc && ./xgcc -B./ t.c.

Thanks for your help. I tried your first suggestion, but it doesn't work:

/home/kevin/Documents/School/Thesis/work/install/llvmgcc-mips/bin/llvm-gcc
-nostdlib -nostdinc
-I/home/kevin/Documents/School/Thesis/work/install/psptoolchain/psp/include
-I/home/kevin/Documents/School/Thesis/work/install/psptoolchain/lib/gcc/psp/4.1.0/include
-c -emit-llvm -Wall \
                -D_PSP_FW_VERSION=150 -DPSP=1 -D__psp__=1 -D_PSP=1
-I/home/kevin/Documents/School/Thesis/work/install/psptoolchain/psp/sdk/include
-O1 main.c -o main.o
llvm-gcc: error trying to exec 'cc1': execvp: No such file or directory

When I ran "make -k install" it looked like every invocation of xgcc
died with an abort (after throwing std::bad_alloc). Something serious
happening here?

Regards,
Kevin André

Do:

   find . -name cc1 -print

to find cc1 in the build directory. Then, copy this file by hand to to llvm-gcc -print-prog-name=cc1.

The destination was unclear, it just printed "cc1" without a
directory. But I found where to put it by looking where cc1 is located
for the other GCCs on my PC. At least I got llvm-gcc running again.
Thanks.

Something is still wrong because I cannot get Pi_Calc to run after
compiling it with this semi-cross-compiler, and it worked with the
regular llvm-gcc. I configured the cross compiler with target
mips-unknown-linux-gnu. Should I use another triple or do I need to
hack the llvm-gcc sources some more?

Hi,

When using mips-unknown-linux-gnu as a cross-compiler, the llvm Mips
backend is called by cc1 and with that you get llvm bytecode defined
relative to the Mips ABI. This can be messing up somehow your
generated C code.

When using mips-unknown-linux-gnu as a cross-compiler, the llvm Mips
backend is called by cc1 and with that you get llvm bytecode defined
relative to the Mips ABI.

That was my intention. The PSP has a 32-bit MIPS (derived) CPU. What I
don't know is if that triple is the right one to pick.
I looked through the patch that turns gcc into psp-gcc and it defines
a special triple called simply "psp":

diff -burN gcc-4.1.0/config.sub gcc-psp/config.sub
--- gcc-4.1.0/config.sub 2005-12-16 12:57:40.000000000 +0000
+++ gcc-psp/config.sub 2006-05-07 13:27:40.000000000 +0100
@@ -264,6 +264,7 @@
   > mipsisa64sb1 | mipsisa64sb1el \
   > mipsisa64sr71k | mipsisa64sr71kel \
   > mipstx39 | mipstx39el \
+ | mipsallegrex | mipsallegrexel \
   > mn10200 | mn10300 \
   > mt \
   > msp430 \
@@ -346,6 +347,7 @@
   > mipsisa64sb1-* | mipsisa64sb1el-* \
   > mipsisa64sr71k-* | mipsisa64sr71kel-* \
   > mipstx39-* | mipstx39el-* \
+ | mipsallegrex-* | mipsallegrexel-* \
   > mmix-* \
   > mt-* \
   > msp430-* \
@@ -689,6 +691,10 @@
     basic_machine=m68k-atari
     os=-mint
     ;;
+ psp)
+ basic_machine=mipsallegrexel-psp
+ os=-elf
+ ;;
   mips3*-*)
     basic_machine=`echo $basic_machine | sed -e 's/mips3/mips64/'`
     ;;

I did not see any changes in the rest of the diff that did something
to the ABI; as far as I understand it it's only adding some extra
instructions. So I assume that the PSP uses a standard MIPS ABI. And
yet something is still wrong, even more than with a native
"i686-pc-linux-gnu" llvm-gcc.

This can be messing up somehow your
generated C code.

Supposed that you knew my approach was intentional (correct me if I'm
wrong), what problem did you see here?

Regards,
Kevin André

Hi Kevin,

Supposed that you knew my approach was intentional (correct me if I'm
wrong), what problem did you see here?

Yes, i'm trying to help raising possible problems. For example, there are
Mips machines with different endianess, the llvm Mips default (Big) is
different from
the psp toochain default one (correct me if I'm wrong - Little), maybe
this is messing
up...

Cheers,

Good point. I added "-EL" to the options to get little-endian code,
but it doesn't solve the problem. And I'm sure the code is compiled as
32-bit because my arch-info program prints 4 for sizeof(int) when
compiled with the current llvm-gcc. Could it be something else I
missed?

Regards,
Kevin

Good point. I added "-EL" to the options to get little-endian code,
but it doesn't solve the problem. And I'm sure the code is compiled as
32-bit because my arch-info program prints 4 for sizeof(int) when
compiled with the current llvm-gcc. Could it be something else I
missed?

I think that "-EL" will no work, I would try changing
DataLayout("E-p:32:32:32") to
DataLayout("e-p:32:32:32") on MipsTargetMachine.cpp, recompile llvm,
cross-compile
llvm-gcc to Mips and then use cc1.

OK, I did this and it works now. Thanks!

Regards,
Kevin André