Bug 15270 - GNU LD produce stale dynamic table entries for symbols optimized out by LTO
Summary: GNU LD produce stale dynamic table entries for symbols optimized out by LTO
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-12 12:59 UTC by Jan Hubicka
Modified: 2013-03-22 23:38 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
untested patch (504 bytes, patch)
2013-03-20 09:11 UTC, Alan Modra
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Hubicka 2013-03-12 12:59:05 UTC
The problem is in detail described in:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56557


Compiling:
//================
#include <fstream>

int main()
{
  std::fstream x;
}
//================

The link error is;

cryolite@ubuntu:~/work/gcc-bugs/20130306$ ~/local/gcc-4.8-20130303/bin/g++
-flto -rdynamic main.cpp

with older revisions of GCC leads to link error. This problem was fixed on GCC side, but there are also useless referneces to symbols.

The resulting binary contains lots of bogus
SHN_UNDEF symbols (using ld.bfd 2.22.52.0.1), including the _ZTC* symbols that
will fail to link against latest 4.8.0 libstdc++ (or 4.7.x libstdc++), because
they aren't exported.
I'd say that the only needed SHN_UNDEF symbols in the dynamic table are the
symbols that are actually used in the relocations.
If I link without -flto, the relocs are:
0000000000600dc0  0000000400000006 R_X86_64_GLOB_DAT      0000000000000000
__gmon_start__ + 0
0000000000600de0  0000000700000007 R_X86_64_JUMP_SLOT     0000000000000000
__libc_start_main + 0
0000000000600de8  0000000c00000007 R_X86_64_JUMP_SLOT     0000000000000000
_ZNSt13basic_fstreamIcSt11char_traitsIcEED1Ev + 0
0000000000600df0  0000000e00000007 R_X86_64_JUMP_SLOT     0000000000000000
_ZNSt13basic_fstreamIcSt11char_traitsIcEEC1Ev + 0
0000000000600df8  0000001200000007 R_X86_64_JUMP_SLOT     0000000000400820
__gxx_personality_v0 + 0
0000000000600e00  0000001300000007 R_X86_64_JUMP_SLOT     0000000000000000
_Unwind_Resume + 0
and SHN_UNDEF symbols in the binary beyond those are just:
     1: 0000000000600e08     0 NOTYPE  WEAK   DEFAULT   24 data_start
     5: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _Jv_RegisterClasses
     8: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND
_ITM_deregisterTMCloneTable
    10: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND
_ITM_registerTMCloneTable
But with -flto there are 96 SHN_UNDEF symbols in the binary.  That looks like
liblto_plugin.so bug to me, the symbols are there just in the symbol tables,
but aren't actually used for anything.
Comment 1 Alan Modra 2013-03-20 09:11:52 UTC
Created attachment 6938 [details]
untested patch

This may be as simple as not setting ref_regular for undefined syms in IR objects that have a definition in a shared library.
Comment 2 Sourceware Commits 2013-03-22 23:35:57 UTC
CVSROOT:	/cvs/src
Module name:	src
Changes by:	amodra@sourceware.org	2013-03-22 23:35:55

Modified files:
	bfd            : ChangeLog elflink.c 

Log message:
	PR ld/15270
	* elflink.c (elf_link_add_object_symbols): Don't set def_regular
	or ref_regular for BFD_PLUGIN owned syms, or have them affect
	def_dynamic/ref_dynamic.
	(_bfd_elf_fix_symbol_flags): Don't set def_regular for BFD_PLUGIN
	owned syms.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/ChangeLog.diff?cvsroot=src&r1=1.5998&r2=1.5999
http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elflink.c.diff?cvsroot=src&r1=1.475&r2=1.476
Comment 3 Alan Modra 2013-03-22 23:38:04 UTC
Fixed mainline