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.
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_commonwhich contains a reference to the__udivdi3function gets a zero instead of erroring out. From the resulting fill.out ELF:compared to with
-lkmc:The original archive,
libgultra_rom.adoes contain the appropriate relocation information. The build process is:I've verified that
codesegment.ostill contains the correct relocation information:Disassembly:
4874: 0c000000 jal 0 <InitDisplayLists>Relocation Info:
00004874 R_MIPS_26 __udivdi3Which 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.