Linkage Problem with GCC 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9)

[vmlemon]

Hi,

I've just tried to build OpenMach, using the build instructions on the project homepage, using the following toolchain configuration:

tyson@tyson-VirtualBox:~/openmach/obj$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.8/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.8.1-10ubuntu9' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-i386 --with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-targets=all --enable-multiarch --disable-werror --with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9) 

It seems that compilation was mostly-successful, however - linkage fails with:

gcc  -L../lib -nostdlib \
        -o bootstrap ../libmach/standalone/mach-crt0.o bootstrap.o def_pager_setup.o default_pager.o exec.o ext2_file_io.o ffs_compat.o ffs_file_io.o file_io.o kalloc.o load.o minix_ffs_compat.o minix_file_io.o strfcns.o translate_root.o wiring.o -lthreads -lmach_exec -lmach_sa
bootstrap.o: In function `main':
bootstrap.c:(.text+0x595): undefined reference to `__stack_chk_fail'
def_pager_setup.o: In function `add_paging_file':
def_pager_setup.c:(.text+0x155): undefined reference to `__stack_chk_fail'
def_pager_setup.o: In function `default_pager_setup':
def_pager_setup.c:(.text+0x2c0): undefined reference to `__stack_chk_fail'
ext2_file_io.o: In function `ext2_open_file':
ext2_file_io.c:(.text+0xd22): undefined reference to `__stack_chk_fail'
ffs_file_io.o: In function `ffs_open_file':
ffs_file_io.c:(.text+0xbf1): undefined reference to `__stack_chk_fail'
load.o:load.c:(.text+0x63c): more undefined references to `__stack_chk_fail' follow
collect2: error: ld returned 1 exit status
make[1]: *** [bootstrap] Error 1

A cursory Google suggests implementing either a dummy version of __stack_chk_fail(void), or passing -fno-stack-protector to GCC during compilation - but I'm not sure if this approach will work, in our case. (Looking at http://stackoverflow.com/questions/4492799/undefined-reference-to-stack-chk-fail)

[vmlemon]

So, it seems that I've made some progress, just now.

After upgrading from Ubuntu 13.10, to 14.04, to receive a slightly newer version of GCC:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.8/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-i386 --with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-targets=all --enable-multiarch --disable-werror --with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) 

And then, editing the DEFINES line in obj/Makeconf to read DEFINES = -D__ELF__=1 -fno-stack-protector -DDEBUG=1 -DHAVE_VPRINTF=1 -DHAVE_STRERROR=1, and finally, manually running make, in obj/kernel, I now have a shiny new kernel image file, and a bootstrap file:

tyson@tyson-VirtualBox:~/openmach/obj$ file bootstrap/bootstrap
bootstrap/bootstrap: ELF 32-bit LSB  executable, Intel 80386, version 1 (SYSV), statically linked, BuildID[sha1]=a71de064002dd2314952669c322a0f6175fe9cf2, not stripped

tyson@tyson-VirtualBox:~/openmach/obj/kernel$ file kernel 
kernel: ELF 32-bit LSB  executable, Intel 80386, version 1 (SYSV), statically linked, not stripped

However, I also receive this error:

make[1]: Leaving directory `/home/tyson/openmach/obj/boot/linux'
MACHBOOTDIR=`cd ./boot/bsd; pwd` \
    ./boot/bsd/mkbsdimage -o ./Mach ./kernel/kernel ./bootstrap/bootstrap
./Mach.mods.S: Assembler messages:
./Mach.mods.S:6: Warning: unterminated string; newline inserted
./Mach.mods.S:7: Warning: unterminated string; newline inserted
./Mach.mods.S:8: Warning: unterminated string; newline inserted
./Mach.mods.S:9: Warning: unterminated string; newline inserted
./Mach.mods.S:10: Warning: unterminated string; newline inserted
./Mach.mods.S:11: Warning: unterminated string; newline inserted
./Mach.mods.S:12: Error: junk at end of line, first unrecognised character is `.'
ld: cannot find ./Mach.mods.o: No such file or directory
make: *** [bsdimage] Error 1

To be honest, given the vintage of the code, we should probably switch on -fno-stack-protector as an interim measure, until we implement our own stack canaries that we can trust to work everywhere, instead of relying on toolchain quirks, and hoping that host distribution/OS suppliers don't pull the rug out from underneath us.

(And for what it's worth, this is the approach that I'm taking in Enryo (my project based on L4Ka::Pistachio)).