This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274

--- Comment #28 from Dave Korn <davek at gcc dot gnu.org> 2011-02-01 06:59:58 UTC ---
It looks like the problem is much earlier than the linker; it looks like the IR
symtabs in the input object files are being generated incorrectly.  Here are
the real symbol tables:

$ ./obj/binutils/.libs/nm-new.exe *.o

abs-1-lib.o:
00000001 C __gnu_lto_v1
         U abort
00000000 T abs
         U abs_called
         U inside_main
00000024 T labs

abs-1.o:
00000001 C __gnu_lto_v1
         U abort
         U abs
00000000 B abs_called
00000000 T main_test

main.o:
00000001 C __gnu_lto_v1
00000004 C inside_main
00000000 T main
         U main_test


And here are the IR symtabs (I built a cross GCC just far enough to get the
liblto_plugin):

$ ./obj/binutils/.libs/nm-new.exe --plugin ./obj-xgcc/lto-plugin/.libs/cyglto_p
lugin-0.dll *.o

abs-1-lib.o:
00000000 T abs
00000000 T abs_called
00000000 T inside_main

abs-1.o:
00000000 T abs
00000000 T abs_called
00000000 T main_test

main.o:
00000000 T inside_main
00000000 T main
00000000 T main_test

To confirm that the symtabs really are wrong in the object files, rather than
that the plugin is misreading them, here's a binary dump from one:

$ ./obj/binutils/.libs/objdump.exe -h abs-1-lib.o

abs-1-lib.o:     file format elf32-hppa-linux

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000058  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         00000000  00000000  00000000  0000008c  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000000  00000000  00000000  0000008c  2**0
                  ALLOC
  3 .gnu.lto_.jmpfuncs.29f392e1 00000019  00000000  00000000  0000008c  2**0
                  CONTENTS, READONLY, EXCLUDE
  4 .gnu.lto_.pureconst.29f392e1 00000016  00000000  00000000  000000a5  2**0
                  CONTENTS, READONLY, EXCLUDE
  5 .gnu.lto_abs.29f392e1 00000192  00000000  00000000  000000bb  2**0
                  CONTENTS, READONLY, EXCLUDE
  6 .gnu.lto_labs.29f392e1 00000189  00000000  00000000  0000024d  2**0
                  CONTENTS, READONLY, EXCLUDE
  7 .gnu.lto_.cgraph.29f392e1 0000003c  00000000  00000000  000003d6  2**0
                  CONTENTS, READONLY, EXCLUDE
  8 .gnu.lto_.vars.29f392e1 00000018  00000000  00000000  00000412  2**0
                  CONTENTS, READONLY, EXCLUDE
  9 .gnu.lto_.refs.29f392e1 0000001b  00000000  00000000  0000042a  2**0
                  CONTENTS, READONLY, EXCLUDE
 10 .gnu.lto_.statics.29f392e1 00000014  00000000  00000000  00000445  2**0
                  CONTENTS, READONLY, EXCLUDE
 11 .gnu.lto_.decls.29f392e1 000002ab  00000000  00000000  00000459  2**0
                  CONTENTS, READONLY, EXCLUDE
 12 .gnu.lto_.symtab.29f392e1 00000048  00000000  00000000  00000704  2**0
                  CONTENTS, READONLY, EXCLUDE
 13 .gnu.lto_.opts 00000012  00000000  00000000  0000074c  2**0
                  CONTENTS, READONLY, EXCLUDE
 14 .PARISC.unwind 00000020  00000000  00000000  00000760  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
 15 .comment      00000042  00000000  00000000  00000780  2**0
                  CONTENTS, READONLY

$ ./obj/binutils/.libs/objcopy.exe -j .gnu.lto_.symtab.29f392e1 abs-1-lib.o sym
s-abs-1-lib.o

$ ./obj/binutils/.libs/objdump.exe -s syms-abs-1-lib.o

syms-abs-1-lib.o:     file format elf32-hppa-linux

Contents of section .gnu.lto_.symtab.29f392e1:
 0000 61627300 00000000 00000000 00000000  abs.............
 0010 00004669 6e736964 655f6d61 696e0000  ..Finside_main..
 0020 00000000 00000000 00000000 00656162  .............eab
 0030 735f6361 6c6c6564 00000000 00000000  s_called........
 0040 00000000 00000067                    .......g

  The format of the IR symtab entries is: 
(variable-length) NUL-terminated name
(variable-length) NUL-terminated comdat group
(1 byte) symbol kind from LDPK_ enumeration
(1 byte) symbol visibility from LDPV_ enumeration
(8 bytes) 64-bit symbol size
(4 bytes) 32-bits symbol aux info.

  As you can see, this symtab claims that abs-1-lib.o defines inside_main

 0000 61627300 00000000 00000000 00000000  abs.............
 0010 00004669 6e736964 655f6d61 696e0000  ..Finside_main..
            \/ \/\/\/\/ \/\/\/\/ \/\/\/\/
name--------++++++++++++++++++++++++++ +
comdat---------------------------------+
 0020 00000000 00000000 00000000 00656162  .............eab
      \/\/
kind--+ +   0 = LDPK_DEF
vis-----+   0 = LDPV_DEFAULT
 0030 735f6361 6c6c6564 00000000 00000000  s_called........
 0040 00000000 00000067                    .......g


So the problem is that the object files are being written incorrectly in the
first place, I think.  Indeed, the contents of abs-1-lib.s look that way:

    .section    .gnu.lto_.symtab.29f392e1,"",@progbits
    .stringz    "abs"
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    "Finside_main"
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    "eabs_called"
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .stringz    ""
    .ascii    "g"
    .text

No attempt there to put anything but zeros for the symbol kind.  So, LTO is
streaming out symtabs that say every object file defines every symbol... no
wonder the linker/plugin get confused!

This now needs somebody with a full compiler for the target to debug; I've only
got (cross) binutils and lto-plugin.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]