No error on undefined references at link time

[ChrisPVille]

When linking an application, it seems that unresolved references are silently ignored, resulting in an incomplete binary.

For example, look at the autofill demo in the official SDK. If you remove the libkmc link argument (i.e. delete -lkmc), the resulting objects link together via Spicy without complaint, but __osInitialize_common which contains a reference to the __udivdi3 function gets a zero instead of erroring out. From the resulting fill.out ELF:

80004ccc:       00862021        addu    a0,a0,a2
80004cd0:       24060000        li      a2,0
80004cd4:       0c000000        jal     80000000 <_zbufferSegmentBssSize+0x7ff8f800> !!!!!!!! 0 !!!!!!!
80004cd8:       24070004        li      a3,4
80004cdc:       3c048000        lui     a0,0x8000

compared to with -lkmc:

80004ccc:       00862021        addu    a0,a0,a2
80004cd0:       24060000        li      a2,0
80004cd4:       0c001b14        jal     80006c50 <__udivdi3>
80004cd8:       24070004        li      a3,4
80004cdc:       3c048000        lui     a0,0x8000

The original archive, libgultra_rom.a does contain the appropriate relocation information. The build process is:

mips64-elf-gcc -DNDEBUG -D_FINALROM -DF3DEX_GBI_2  -I. -I<path>/include/PR -G 0 -c -I<path>/include -D_MIPS_SZLONG=32 -D_MIPS_SZINT=32 -D_LANGUAGE_C -D_ULTRA64 -D__EXTENSIONS__ -mabi=32 -march=vr4300 -mtune=vr4300 -O2 fill.c
mips64-elf-gcc -DNDEBUG -D_FINALROM -DF3DEX_GBI_2  -I. -I<path>/include/PR -G 0 -c -I<path>/include -D_MIPS_SZLONG=32 -D_MIPS_SZINT=32 -D_LANGUAGE_C -D_ULTRA64 -D__EXTENSIONS__ -mabi=32 -march=vr4300 -mtune=vr4300 -O2 static.c
mips64-elf-gcc -DNDEBUG -D_FINALROM -DF3DEX_GBI_2  -I. -I<path>/include/PR -G 0 -c -I<path>/include -D_MIPS_SZLONG=32 -D_MIPS_SZINT=32 -D_LANGUAGE_C -D_ULTRA64 -D__EXTENSIONS__ -mabi=32 -march=vr4300 -mtune=vr4300 -O2 tris.c
mips64-elf-gcc -DNDEBUG -D_FINALROM -DF3DEX_GBI_2  -I. -I<path>/include/PR -G 0 -c -I<path>/include -D_MIPS_SZLONG=32 -D_MIPS_SZINT=32 -D_LANGUAGE_C -D_ULTRA64 -D__EXTENSIONS__ -mabi=32 -march=vr4300 -mtune=vr4300 -O2 controller.c
mips64-elf-gcc -DNDEBUG -D_FINALROM -DF3DEX_GBI_2  -I. -I<path>/include/PR -G 0 -c -I<path>/include -D_MIPS_SZLONG=32 -D_MIPS_SZINT=32 -D_LANGUAGE_C -D_ULTRA64 -D__EXTENSIONS__ -mabi=32 -march=vr4300 -mtune=vr4300 -O2 timer.c
mips64-elf-gcc -DNDEBUG -D_FINALROM -DF3DEX_GBI_2  -I. -I<path>/include/PR -G 0 -c -I<path>/include -D_MIPS_SZLONG=32 -D_MIPS_SZINT=32 -D_LANGUAGE_C -D_ULTRA64 -D__EXTENSIONS__ -mabi=32 -march=vr4300 -mtune=vr4300 -O2 rdp_output.c
mips64-elf-gcc -DNDEBUG -D_FINALROM -DF3DEX_GBI_2  -I. -I<path>/include/PR -G 0 -c -I<path>/include -D_MIPS_SZLONG=32 -D_MIPS_SZINT=32 -D_LANGUAGE_C -D_ULTRA64 -D__EXTENSIONS__ -mabi=32 -march=vr4300 -mtune=vr4300 -O2 dram_stack.c
mips64-elf-ld -o codesegment.o -r fill.o static.o tris.o controller.o timer.o rdp_output.o dram_stack.o   -L<path>/lib -lgultra_rom -L<path>/GCC/mipse/lib
mips64-elf-gcc -DNDEBUG -D_FINALROM -DF3DEX_GBI_2  -I. -I<path>/include/PR -G 0 -c -I<path>/include -D_MIPS_SZLONG=32 -D_MIPS_SZINT=32 -D_LANGUAGE_C -D_ULTRA64 -D__EXTENSIONS__ -mabi=32 -march=vr4300 -mtune=vr4300 -O2 zbuffer.c
mips64-elf-gcc -DNDEBUG -D_FINALROM -DF3DEX_GBI_2  -I. -I<path>/include/PR -G 0 -c -I<path>/include -D_MIPS_SZLONG=32 -D_MIPS_SZINT=32 -D_LANGUAGE_C -D_ULTRA64 -D__EXTENSIONS__ -mabi=32 -march=vr4300 -mtune=vr4300 -O2 cfb.c
mips64-elf-gcc -DNDEBUG -D_FINALROM -DF3DEX_GBI_2  -I. -I<path>/include/PR -G 0 -c -I<path>/include -D_MIPS_SZLONG=32 -D_MIPS_SZINT=32 -D_LANGUAGE_C -D_ULTRA64 -D__EXTENSIONS__ -mabi=32 -march=vr4300 -mtune=vr4300 -O2 cfb_b.c
spicy -s 9 -r fill.n64 -e fill.out spec
makemask fill.n64

I've verified that codesegment.o still contains the correct relocation information:
Disassembly: 4874: 0c000000 jal 0 <InitDisplayLists>
Relocation Info: 00004874 R_MIPS_26 __udivdi3

Which is expected, as it does link correctly when I give it the correct objects. Again, my problem is that there is no error or warning when the symbol is unresolved. This appears to be similar behavior to --unresolved-symbols=ignore-all, but a cursory look though Spicy didn't reveal that argument being passed to ld.

[ChrisPVille]

The noinhibit-exec flag causes many errors to be ignored, including unresolved symbols and overlapping sections. It also appears the overlapping section flag had no effect as a result as they were always ignored. I can make a PR if this looks like good solution. Sometimes it's helpful to get a broken binary rather than nothing at all, but that can be a dangerous default.

[trhodeos]

Hey Chris, thanks for filing the issue. Please submit a PR and I'll merge it!