Bug 21900 - [MIPS] linking shared library with -z defs --warn-unresolved-symbols emits null relocation
Summary: [MIPS] linking shared library with -z defs --warn-unresolved-symbols emits nu...
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.29
: P2 normal
Target Milestone: 2.31
Assignee: Maciej W. Rozycki
Depends on:
Reported: 2017-08-03 15:45 UTC by James Cowgill
Modified: 2018-03-31 12:32 UTC (History)
2 users (show)

See Also:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description James Cowgill 2017-08-03 15:45:26 UTC

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:


Comment 1 cvs-commit@gcc.gnu.org 2018-03-03 15:53:03 UTC
The master branch has been updated by Maciej W. Rozycki <macro@sourceware.org>:


commit dfb93f11587ca08b820c7c785278366f2505cfd1
Author: James Cowgill <james.cowgill@mips.com>
Date:   Sat Mar 3 15:49:21 2018 +0000

    PR ld/21900: MIPS: Fix relocation processing with undefined symbols
    Currently, when `mips_elf_calculate_relocation' is asked to relocate an
    undefined symbol, it reports an error or a warning and immediately
    returns without performing the relocation.  This is fine if the link
    fails, but if unresolved_syms_in_objects == RM_GENERATE_WARNING, the
    link will continue and output some unrelocated code, which is a
    regression from commit e7e2196da3f0 ("MIPS/BFD: Correctly report
    undefined relocations").
    Fix this by continuing after calling the `undefined_symbol' hook unless
    this is an error condition.
    	PR ld/21900
    	* elfxx-mips.c (mips_elf_calculate_relocation): Only return
    	after calling `undefined_symbol' hook if this is an error
    	condition.  Assume the value of 0 for the symbol requested
    	PR ld/21900
    	* testsuite/ld-mips-elf/undefined-warn.d: New test.
    	* testsuite/ld-mips-elf/undefined.s: Add padding at the end.
    	* testsuite/ld-mips-elf/mips-elf.exp: Run the new test.
Comment 2 Maciej W. Rozycki 2018-03-03 15:56:02 UTC