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/53831] Inline virtuals missing in LTO symtab


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

--- Comment #6 from Yuri Gribov <tetra2005 at gmail dot com> 2012-07-03 12:16:21 UTC ---
First of all note that we are talking about _ZN1C1fEv (not _ZN1C1gEv!) here.

I agree that linker doesn't mention it in the resolution file but I think this
happens because it's missing in impl.o's lto_.symtab section:
  $ cat impl.s | grep -C 5 lto_.symtab
  ...
  .section        .gnu.lto_.symtab.919ce2eae4796a64,"",%progbits
  .ascii  "_ZN1C1gEv\000\000\000\000\000\000\000\000\000\000\000"
  .ascii  "\000\241\000\000\000_ZTV1C\000\000\000\000\000\000\000"
  .ascii  "\000\000\000\000\000\265\000\000\000"
  .text
  .section        .gnu.lto_.opts,"",%progbits
Thus it isn't reported to linker by lto-plugin via add_symbols() (see
ld/plugin.c). So linker doesn't have a chance to know that _ZN1C1fEv is
actually defined in impl.o and generates invalid resolution. I still think that
ld is innocent here.

Did I get it all wrong?


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