On MIPS, using "-z defs" and "--warn-unresolved-symbols" while building a shared library with undefined symbols seems to cause all the relocations which use those symbols to be filled with null values. The executables then crash when executed because they load a garbage address into t9 and jump to it. Here is an example:
> $ cat undef.c
> int parent(void);
> int child(void)
> return parent();
> $ mips-linux-gnu-gcc -c -fPIC -O2 undef.c
> $ ../build-mips/ld/ld-new -EB -shared -z defs --warn-unresolved-symbols undef.o -o libundef.so
> undef.o: In function `child':
> undef.c:(.text+0xc): warning: undefined reference to `parent'
> undef.c:(.text+0x10): warning: undefined reference to `parent'
> $ mips-linux-gnu-objdump -dr libundef.so
> libundef.so: file format elf32-tradbigmips
> Disassembly of section .text:
> 00000300 <child>:
> 300: 3c1c0002 lui gp,0x2
> 304: 279c8030 addiu gp,gp,-32720
> 308: 0399e021 addu gp,gp,t9
> 30c: 8f990000 lw t9,0(gp)
> 310: 03200008 jr t9
> 314: 00000000 nop
Note the line:
> lw t9,0(gp)
I would have expected a different offset than 0. If you remove the "-z defs" option to ld, a valid library is generated.
This was observed while trying to debug a long standing issue where gnome-settings-daemon would immediately SIGBUS on startup. I have not personally tested old versions of binutils, but this bug suggests that it was broken on 2011 and a similar bug affects (or affected) ia64 as well: