This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: dwarf2out var loc handling fix
- From: Jakub Jelinek <jakub at redhat dot com>
- To: David Daney <ddaney at caviumnetworks dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, gcc-patches at gcc dot gnu dot org, rguenther at suse dot de, jakub at redhat dot com, jason at redhat dot com, Adam Nemet <anemet at caviumnetworks dot com>
- Date: Fri, 25 Sep 2009 20:58:31 +0200
- Subject: Re: dwarf2out var loc handling fix
- References: <20090921114119.GB29481@kam.mff.cuni.cz> <4ABCF377.2000809@caviumnetworks.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Sep 25, 2009 at 09:44:39AM -0700, David Daney wrote:
> We get a reference to the external symbol 'munmap' in the .debug_info
> section.
>
> $ grep munmap testcase-min4.s
> lw $25,%call16(munmap)($28)
> .4byte munmap
> .ascii "munmap\000"
> .ascii "munmap_adaptor<void*, unsigned int>\000"
>
> This is not good because when we try to link the shared object ld fails
> with:
>
> /usr/local/mips64-unknown-linux-gnu/bin/ld: non-dynamic relocations
> refer to dynamic symbol munmap@@GLIBC_2.0
> /usr/local/mips64-unknown-linux-gnu/bin/ld: failed to set dynamic
> section sizes: Bad value
The patch just caused that it isn't being thrown away, before it was just a
latent issue on this testcase.
The same testcase compiled with -g -O2 -fpic fails to link into shared
library on x86_64 as well:
/usr/bin/ld: /tmp/cc2r0a6c.o: relocation R_X86_64_PC32 against undefined
symbol `munmap@@GLIBC_2.2.5' can not be used when making a shared object; /recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
While it e.g. links on i386, the relocation against munmap is lost (the
linker doesn't create .reloc.debug_info with the relocations that still
haven't been applied) and so the const value is 0.
I guess we'll need to limit here to symbols emitted in the current
translation unit.
Jakub