Hi, the problem I keep running into is something that I don't fully understand (yet). I wrote a new backend for GCC, ported the GNU-Toolchain to my target and got it running. The next thing I did: I wrote a small helloworld.c a start.s and an end.s. Everything that is needed is included in those files. When building the program myself: eco32-elf-gcc -S helloworld.c eco32-elf-as -o hello.o start.s helloworld.s end.s eco32-elf-ld -o hello.elf hello.o everything works like a charm. The program even runs in the simulator (after using eco32-elf-objdump -O binary hello.elf hello.bin) After that I tried using only gcc: gcc -o hello.elf start.s helloworld.c end.s after that I got "ld can't find crt0.o". crt0.o normally comes with the clibrary (that isn't present at the moment => I will do that after I confirmed my GCC cross is working correctly) So I used as and ld to produce crt0.o from start.s and end.s and put it into the path for this cross-toolchain. Well the resulting elf32 binary had complete wrong branch/jump relocations (wrong offset). And even with adding my own linkderscript with -T stdalone.lds and specifying -nostdlib and -nostdinc the result still was as horrible as before. To sum it up, I suspect that either I did something wrong or GCC is giving some options to ld (or as) that cause this behaviour. I could really use a pointer in the right direction with this. First I suspected the tool-chain but the my procedure shows that it works correctly. With best regards ~ Jens
