Hi,

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:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620874#40

Thanks,
James