If I compile and link a file with -m68000 option the code contains still 68040 instructions in startup and finish code. We use the linker script mvem162.ld from Newlib which includes the .init and .fini sections (I think they are only necessary in C++ and Java). The problem is that the crtstuff.c code is compiled with xgcc without any options which results in 68040. If the Makefile.in is patched so that it contains -m68000, all works.
The top-level multilib directory is compiled for the "default" target, which is in some cases m68000, and in some cases m68020. m68k-elf defaults to m68000. Perhaps your linker script doesn't look into the m68040 subdirectory to fetch the correct version of crt0.o? Please attach your linker script.
Created attachment 7727 [details] The linker script
I don't understand. Why should it search in 68040 directory? There is probably m68040 code, but if I compile with -m68000 I *don't* want 68040 code but plain 68000 code.
Sorry, I've read your report vice-versa, because that's the most likely thing that could have happened (there were so many bogus uClinux reports that I finally decided to remove m68000 libraries from the toolchain distribution). Could you please add "-v" to your link command line and see what it says? You should see the m68k-elf-ld invocation with its full command-line. Now, I see that invoking gcc without any -m680x0 option would not generate code for 68020 by default: ---cut--- m68020-*-elf* | m68k-*-elf*) tm_file="m68k/m68k.h m68k/m68k-none.h m68k/m68kelf.h dbxelf.h elfos.h m68k/m68kemb.h m68k/m68020-elf.h" tm_defines="MOTOROLA USE_GAS" tmake_file=m68k/t-m68kelf extra_parts="crtbegin.o crtend.o" use_fixproto=yes ;; ---cut--- (don't get fooled by the m68020-elf.h header, it just contains two harmless definitions).
It's m68k-elf-gcc -o test.out test.o -lm -m68000 -Wl,-Tmvme162.ld -Wl,-v collect2-Version 3.4.3 (68k, Motorola syntax) /opt/m68k/lib/gcc/m68k-elf/3.4.3/../../../../m68k-elf/bin/ld -o test.out /opt/m68k/lib/gcc/m68k-elf/3.4.3/crtbegin.o -L/opt/m68k/lib/gcc/m68k-elf/3.4.3/m68000 -L/opt/m68k/lib/gcc/m68k-elf/3.4.3 -L/opt/m68k/lib/gcc/m68k-elf/3.4.3/../../../../m68k-elf/lib/m68000 -L/opt/m68k/lib/gcc/m68k-elf/3.4.3/../../../../m68k-elf/lib test.o -lm -Tmvme162.ld -v -lgcc -lc -lgcc /opt/m68k/lib/gcc/m68k-elf/3.4.3/crtend.o the problematic code is in /opt/m68k/lib/gcc/m68k-elf/3.4.3/crtend.o. The attached patch for gcc (sorry, I thought I attached it) fixes the proxlem for me.
Created attachment 7737 [details] Patch that fixed the problem for me.
All this configury stuff got changed a while back. By default the m68k-elf configuration uses m68020. There is a multilib for m68000 that only uses m68000 instructions. I've looked at the generated code and well as the build logs. FOr the m68000 multilib, I don't see anything other than pure m68000 code in crtbegin/crtend.o. In the build logs I see the proper -mcpu=68000 option when building the m68000 multilibs. I'm going close this as resolved since it looks like everything is working as it should now.