binutils ld emitting ARM BLX instructions when using armv4 target

I wish to compile C programs for a Samsung S3C2440 SoC (based on ARM920T core) running Linux 2.6.32.2 kernel. I have an existing Gentoo Linux install running on an ARM926EJS.

I compile C programs for the S3C2440 using the following gcc options :

gcc -mcpu=arm920t -o hello hello.c

Upon running the compiled executable (a single printf "hello world"), I simply get 'Illegal Instruction'. I have no GDB compiled for the target, and dmesg doesn't report the address of a faulting instruction.

I see that running "objdump -d" on the executable lists a BLX instruction which apparently is not supported on the ARM920T core.

# gcc -mcpu=arm920t -o hello hello.c && objdump -d hello|grep blx
83cc:       e12fff33        blx     r3

With further investigation, it seems that BLX is used for Thumb support with GNU-EABI binaries, and is generated by 'ld'. Using GCC's '-c' option to just compile seems to confirm this, as no BLX instruction are in the objdump -d output for the object file alone.

Would the BLX instructions be the problem I'm having, and if so, how do I tell 'ld' to not generate BLX instructions in the final linked executable?

Software versions :

# ld -V
GNU ld (GNU Binutils) 2.20.1.20100303
  Supported emulations:
   armelf_linux_eabi
   armelfb_linux_eabi

# gcc -v
Using built-in specs.
Target: armv5tel-softfloat-linux-gnueabi
Configured with: /var/tmp/portage/sys-devel/gcc-4.4.5/work/gcc-4.4.5/configure --prefix=/usr --bindir=/usr/armv5tel-softfloat-linux-gnueabi/gcc-bin/4.4.5 --includedir=/usr/lib/gcc/armv5tel-softfloat-linux-gnueabi/4.4.5/include --datadir=/usr/share/gcc-data/armv5tel-softfloat-linux-gnueabi/4.4.5 --mandir=/usr/开发者_高级运维share/gcc-data/armv5tel-softfloat-linux-gnueabi/4.4.5/man --infodir=/usr/share/gcc-data/armv5tel-softfloat-linux-gnueabi/4.4.5/info --with-gxx-include-dir=/usr/lib/gcc/armv5tel-softfloat-linux-gnueabi/4.4.5/include/g++-v4 --host=armv5tel-softfloat-linux-gnueabi --build=armv5tel-softfloat-linux-gnueabi --disable-altivec --disable-fixed-point --without-ppl --without-cloog --with-float=soft --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/armv5tel-softfloat-linux-gnueabi/4.4.5/python --enable-checking=release --disable-libgcj --with-arch=armv5te --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.4.5 p1.2, pie-0.4.5'
Thread model: posix
gcc version 4.4.5 (Gentoo 4.4.5 p1.2, pie-0.4.5) 

Is the BLX coming from user code or library code? Since you're not passing -mthumb I'd bet on the library. It seems your GCC was configured for armv5tel, so probably either libc or the startup code was compiled with use of BLX, which is supported on ARMv5. If you're not sure, upload the binary somewhere.

I see several things you can try:

1. Try adding -mthumb-interwork (unlikely to help IMO)
2. Try linking dynamically, if it's not already the case.
3. Try rebuilding your GCC/libc specifically for armv4. I'm not certain how it's done but e.g. CodeSourcery toolchain has separate set of libraries and startup code for armv4.