[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #34 from vincenzo Innocente 2012-05-14 07:41:02 UTC --- I've created PR53337

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 Jan Hubicka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #32 from vincenzo Innocente 2012-05-10 17:13:20 UTC --- On 10 May, 2012, at 7:07 PM, hubicka at ucw dot cz wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 > > --- Comment #31 from Jan Hubicka 2012-05-10 17:07:47 > UTC -

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #31 from Jan Hubicka 2012-05-10 17:07:47 UTC --- > using the new binutil I've no more error > still warning of the type > tmp/innocent/ccmPaLCz.ltrans6.ltrans.o:ccmPaLCz.ltrans6.o:function > _ZTVN5boost16exception_detail10clone_implIN

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #30 from vincenzo Innocente 2012-05-10 15:50:15 UTC --- using the new binutil I've no more error still warning of the type tmp/innocent/ccmPaLCz.ltrans6.ltrans.o:ccmPaLCz.ltrans6.o:function _ZTVN5boost16exception_detail10clone_implINS

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #29 from vincenzo Innocente 2012-05-10 07:53:37 UTC --- we will try binutil 2.22 in any case the test case is simple (with boost 1.49) notice how w/o linker-plugin NO symbol at all are generated for boost::exception_detail::clone_imp

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #28 from Richard Guenther 2012-05-10 07:35:02 UTC --- I believe binutils 2.21.1 is not new enough, support for this was only added on the 2.22 branch.

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 vincenzo Innocente changed: What|Removed |Added CC||vincenzo.innocente at cern

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #26 from Jan Hubicka 2011-10-02 10:41:27 UTC --- Author: hubicka Date: Sun Oct 2 10:41:24 2011 New Revision: 179424 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179424 Log: PR lto/47247 * lto-plugin.c (get_symbols_v

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #25 from Jan Hubicka 2011-09-28 12:38:29 UTC --- Thanks for gold support. GCC support is now posted at http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01818.html We miss the GNU LD variant http://sourceware.org/bugzilla/show_bug.cgi?id=

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #24 from Cary Coutant 2011-09-26 23:32:17 UTC --- Author: ccoutant Date: Mon Sep 26 23:32:13 2011 New Revision: 179220 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179220 Log: PR lto/47247 * plugin-api.h (enum ld_plu

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #22 from Jan Hubicka 2011-08-27 17:35:27 UTC --- Carry, is there any chance to move ahead on this problem? I see you posted the PREVAILING_DEF_IRONLY_EXP but it was never committed. Concerning Rafael's comment: Why is PREVAILING_D

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #21 from Rafael Avila de Espindola 2011-02-17 01:13:35 UTC --- Most of it is in the string table. Ian gave me some pointers and I will try to fix it tomorrow :-)

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #20 from ccoutant at google dot com 2011-02-16 23:35:28 UTC --- > I have created a "small" test of the symbol table problem. It is in > > http://people.mozilla.com/~respindola/test.tar.xz > > The test is firefox's libxul with most files

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #19 from Jan Hubicka 2011-02-16 23:12:32 UTC --- > 39339456 libxul1.so > 34436696 libxul2.so Yep, it seems similar to what I was getting. Quite important difference and all the stuff gets loaded into memory at startup by dynamic lin

Re: [Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

> 39339456 libxul1.so > 34436696 libxul2.so Yep, it seems similar to what I was getting. Quite important difference and all the stuff gets loaded into memory at startup by dynamic linker. > For a 5 MB reduction I might end up writing a wrapper that runs ld twice :-) You might try GNU-ld's plug

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #18 from Rafael Avila de Espindola 2011-02-16 16:14:52 UTC --- I have created a "small" test of the symbol table problem. It is in http://people.mozilla.com/~respindola/test.tar.xz The test is firefox's libxul with most files copied

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #17 from Jan Hubicka 2011-02-16 07:50:48 UTC --- > I see. Even with PREVAILING_DEF_IRONLY_EXP we still have to update gold to > drop > those, no? Gold doesn't know the language semantics to know which visible I assume it will be par

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #16 from Rafael Avila de Espindola 2011-02-16 04:03:36 UTC --- > The problem is with dropping linkonce_odr that has been previously reported. > This way gold will allocate entry in the dynamic symbol table (you can see it > in > nm of

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #15 from Jan Hubicka 2011-02-15 23:20:40 UTC --- > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 > > --- Comment #14 from Rafael Avila de Espindola com> 2011-02-15 19:39:09 UTC --- > Sorry, can you expand on what gcc was doing t

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #14 from Rafael Avila de Espindola 2011-02-15 19:39:09 UTC --- Sorry, can you expand on what gcc was doing that was causing it to expand the dynamic symbol table? With LLVM what we are doing is *) Report all symbols *) Any symbol not

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #13 from Jan Hubicka 2011-02-15 18:49:15 UTC --- > A quick summary to see if got this right: Yes, the summary seems right. Note that GCC plays now games with not putting COMDATs into LTO symbol table unless they really need to be un

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #12 from Rafael Avila de Espindola 2011-02-14 19:59:22 UTC --- A quick summary to see if got this right: Currently the linker has three options for a symbol in a comdat: *) pick one not in the IL. The plugin gets a PREEMPTED_REG *) p

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #11 from H.J. Lu 2011-01-10 21:01:55 UTC --- (In reply to comment #10) > > What undesirable things may happen if we mark a COMDAT symbol > > PREVAILING_DEF? Is that we won't know which one will be used > > if both LTO and non-LTO obje

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #10 from Jan Hubicka 2011-01-10 20:56:23 UTC --- > What undesirable things may happen if we mark a COMDAT symbol > PREVAILING_DEF? Is that we won't know which one will be used > if both LTO and non-LTO objects define the same COMAT sy

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #9 from Cary Coutant 2011-01-10 19:07:54 UTC --- I've added a new disposition code LDPR_PREVAILING_DEF_IRONLY_EXP and a new version of the GET_SYMBOLS interface to the API specification on the wiki: http://gcc.gnu.org/wiki/whopr/driv

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 Cary Coutant changed: What|Removed |Added CC||ccoutant at gcc dot gnu.org --- Comment #8

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #7 from H.J. Lu 2011-01-10 18:26:00 UTC --- (In reply to comment #6) > The plugin specification says that once the COMDAT is marked PREVAILING, it > has > to be output. > "Any symbol marked PREVAILING_DEF must be defined in one obj

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #6 from Jan Hubicka 2011-01-10 17:54:51 UTC --- The plugin specification says that once the COMDAT is marked PREVAILING, it has to be output. "Any symbol marked PREVAILING_DEF must be defined in one object file added to the link aft

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #5 from H.J. Lu 2011-01-10 17:13:46 UTC --- (In reply to comment #4) > > Can we mark the symbol COMDAT when we generate the output? > What symbol and what output? > > Honza I don't think hjl/lto-mixed branch has the problem --- Cur

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #4 from Jan Hubicka 2011-01-10 17:10:52 UTC --- > Can we mark the symbol COMDAT when we generate the output? What symbol and what output? Honza

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #3 from H.J. Lu 2011-01-10 17:04:30 UTC --- Can we mark the symbol COMDAT when we generate the output?

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #2 from H.J. Lu 2011-01-10 17:02:02 UTC --- Do we have a small testcase to experiment with?

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|