http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56557
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-11
09:27:10 UTC ---
If I change:
--- cp/class.c (revision 196593)
+++ cp/class.c (working copy)
@@ -8364,7 +8364,7 @@ build_ctor_vtbl_group (tree binfo, tree
targets that don't support hidden visibility, this tells
can_refer_decl_in_current_unit_p not to assume that it's safe to
access from a different compilation unit (bz 54314). */
- DECL_VISIBILITY (vtbl) = VISIBILITY_HIDDEN;
+ DECL_VISIBILITY (vtbl) = VISIBILITY_DEFAULT;
DECL_VISIBILITY_SPECIFIED (vtbl) = true;
v = NULL;
(remember, gimple-fold.c still uses the nonsensical DECL_VISIBILITY_SPECIFIED
test rather than actually looking what the visibility is) and link against
older
libstdc++ (one before r195550 fix), the testcase links, but 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.
