Self Hosted GCC Error: internal compiler error: Illegal inst

[Theldus]

Hi,

In recent weeks, I was trying to port GCC/Binutils to the operating system I'm working on. After some trial and error, I was able to successfully build the Cross-Compiler and OS-specific toolchain. While as and ld work like a charm for creating small handwritten asm files, GCC can't build a simple world hello, my setup is as follows:

GCC 6.4.0
Binutils 2.27
Newlib 2.2.0

Code: Select all

gcc -v -c hello.c -o
Using built-in specs.
COLLECT_GCC=gcc
Target: i386-elf-nanvix
Configured with: /media/file/SO/STANDALONE_TOOLCHAIN/LEGACY/SRC/gcc-6.4.0/configure --host=i386-elf-nanvix --target=i386-elf-nanvix --prefix=/media/file/SO/STANDALONE_TOOLCHAIN/LEGACY/HOSTED/PREFIX --with-arch=i386 --with-buid-sysroot=/media/file/SO/STANDALONE_TOOLCHAIN/LEGACY/HOSTED/SYSROOT/ --with-sysroot=/ --with-gmp=/media/file/SO/STANDALONE_TOOLCHAIN/LEGACY/HOSTED/PREFIX --with-mpfr=/media/file/SO/STANDALONE_TOOLCHAIN/LEGACY/HOSTED/PREFIX --with-mpc=/media/file/SO/STANDALONE_TOOLCHAIN/LEGACY/HOSTED/PREFIX --enable-languages=c --disable-libssp --disable-lto --disable-shared --disable-multilib --without-headers --without-isl --disable-nls --disable-werror --disable-hosted-libstdcxx --disable-__cxa_atexit --disable-initfini-array
Thread model: single
gcc version 6.4.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=i386' '-march=i386'
 /bin/../libexec/gcc/i386-elf-nanvix/6.4.0/cc1 -quiet -v -iprefix /bin/../lib/gcc/i386-elf-nanvix/6.4.0/ hello.c -quiet -dumpbase hello.c -mtune=i386 -march=i386 -auxbase hello -version -o ./cc4I4XSb.s
sysconf name: 11, exceeds the values supported!
sysconf name: 11, exceeds the values supported!
sysconf name: 11, exceeds the values supported!
GNU C11 (GCC) version 6.4.0 (i386-elf-nanvix)
	compiled by GNU C version 6.4.0, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory "/bin/../lib/gcc/i386-elf-nanvix/6.4.0/../../../../i386-elf-nanvix/include"
ignoring duplicate directory "/bin/../lib/gcc/../../lib/gcc/i386-elf-nanvix/6.4.0/include"
ignoring nonexistent directory "/usr/local/include"
ignoring duplicate directory "/bin/../lib/gcc/../../lib/gcc/i386-elf-nanvix/6.4.0/include-fixed"
ignoring nonexistent directory "/bin/../lib/gcc/../../lib/gcc/i386-elf-nanvix/6.4.0/../../../../i386-elf-nanvix/include"
#include "..." search starts here:
#include <...> search starts here:
 /bin/../lib/gcc/i386-elf-nanvix/6.4.0/include
 /bin/../lib/gcc/i386-elf-nanvix/6.4.0/include-fixed
 /usr/include
End of search list.
GNU C11 (GCC) version 6.4.0 (i386-elf-nanvix)
	compiled by GNU C version 6.4.0, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: a4837789e1b5a2c760942e5d141fa997
hello.c:1:0: internal compiler error: Illegal instruction
 #include <stdio.h>
 
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

why is GCC reporting '#include <stdio.h>' as illegal instruction?

[nullplan]

My guess is that one of the subprocesses, e.g. cpp, or cc1, has failed with SIGILL. I'd recommend running the entire thing with strace -f, to find that out. Common reason for this failure is wrong compiler settings, so the compiler was compiled for the wrong machine.

[Theldus]

My guess is that one of the subprocesses, e.g. cpp, or cc1, has failed with SIGILL. I'd recommend running the entire thing with strace -f, to find that out. Common reason for this failure is wrong compiler settings, so the compiler was compiled for the wrong machine.

Right in the bull's-eye. Sorry if I was not clear, but the above output is straight from my OS, rather than my Linux machine.

Anyway, the problem was exactly that. GCC registers some signals to the program, including SIGILL. This SIGILL was coming from gcc_src/libcpp/lex.c. The GCC lexer uses SIMD instructions to speed up the analysis, and at run-time (via CPUID) decides which version of the search_line_ * routines should be executed, either 'normal', MMX, SSE2 or SSE4.2 .

Since the OS was not even enabling SSE (well, I didn't expect any program to use it) It was producing 'Invalid Opcode Exception'.
----

Fixed this, GCC was able to run 'fine'... now I need to investigate why the final binary is corrupted: the object file is generated correctly, but the final binary isn't... well, one thing at a time.

Thank you @nullplan.