[Bug gas/25295] Gas should have way to define symbol version without exporting its target
https://sourceware.org/bugzilla/show_bug.cgi?id=25295 --- Comment #5 from hubicka at ucw dot cz --- > Where do you see "export foo and foo@VERS_1"? All I see is that the alias > gets > the same attributes as the original symbol, thus it will be external iff the > original symbol is. Yes, but I want to implement only foo@VERS_1 in the unit, not foo, so I do not want to see foo in the symbol table, just foo@VERS_1 and this does not seem to be possible with current .symver (there is @@@ vairant that does that for default defs) Honza -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25333] GAS is slow processing units compiled with -fdebug-types-sections containing many types
https://sourceware.org/bugzilla/show_bug.cgi?id=25333 --- Comment #2 from hubicka at ucw dot cz --- The testcase was based on real world one - in C++ it is quite easy to create many types. So it would be nice to do something about it. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/19842] LTO build fails to write call address for weak symbol reference
https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #32 from hubicka at ucw dot cz --- > Hi all, > > Just following up on this as it seems to have stalled: @honza, do you concur > this may be a bug in GCC? If so shall I file something, or are you happy to > capture it appropriately? If the resolution is PREVAILING_DEF then indeed GCC should not take it away. As I understand, there is only proprietary testcase. Would be possible to compile it with --save-temps -fdump-ipa-all and lookup the symbol in question in .wpa.*cgraph and .wpa.*whole-program dumps or attach the dumps somewhere for me to explore? Honza -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/17422] binutils should support more than one plugin in lib/bfd-plugins and load the right one
https://sourceware.org/bugzilla/show_bug.cgi?id=17422 --- Comment #4 from hubicka at ucw dot cz --- Actually I think goldld could be updated to load multiple plugins at once and let different plugins to claim different object files. That way we ought to be able to link program that contains LTO objects from multiple compilers (such as GCC and LLVM or different versions of same copmiler). Even code quality should not be that bad given that resolution info will give quite precise idea about the interfaces from each of LTO blobs. Honza -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/13227] GCC now produce slim LTO files. Those can't be linked/archived or nm w/o plugin used. It would be useful to output diagnostics when user attempts so
https://sourceware.org/bugzilla/show_bug.cgi?id=13227 --- Comment #10 from hubicka at ucw dot cz --- Fixed Thanks, does this also cover gold linker? Honza -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/13227] GCC now produce slim LTO files. Those can't be linked/archived or nm w/o plugin used. It would be useful to output diagnostics when user attempts so
https://sourceware.org/bugzilla/show_bug.cgi?id=13227 --- Comment #7 from hubicka at ucw dot cz --- So is it sufficient (and safe) to warn just on the presence of __gnu_slim_lto? Yes, when __gnu_slim_lto gets into linking/archiving/nm, I think it is safe to warn about missing plugin. Honza -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/13227] GCC now produce slim LTO files. Those can't be linked/archived or nm w/o plugin used. It would be useful to output diagnostics when user attempts so
https://sourceware.org/bugzilla/show_bug.cgi?id=13227 --- Comment #2 from hubicka at ucw dot cz --- Bug 14698 Summary: ar, nm and ranlib don't use gcc's liblto_plugin.so in BINDIR/../lib/bfd-plugins automatically https://sourceware.org/bugzilla/show_bug.cgi?id=14698 Will we now get some sort of warning/error when the LTO objects are used but plugin is not found in the search path? Honza -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/14342] [gold] symbol 'std::__once_callable' used as both __thread and non-__thread
http://sourceware.org/bugzilla/show_bug.cgi?id=14342 --- Comment #5 from hubicka at ucw dot cz --- I thought GNU ld didn't have this bug, but I'll check. It reproduced for me for both GNU ld and gold in the latest release version. The testcase seen by GCC may be different from normal file, since libgcov is runtime library (there is some magic of passing it down to linker and allow new references to it to be born at LTO plugin). The way to disable workaround I put in place in mainline GCC is to turn flag_lto into 0 in all occurences in tree-profile.c It should trigger failure of ./gcc.dg/tree-prof/crossmodule-indircall-1.c Honza -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/15516] GNU LD is confused when linker plugin turns COMDAT symbol into static w/o renaming.
http://sourceware.org/bugzilla/show_bug.cgi?id=15516 --- Comment #6 from hubicka at ucw dot cz 2013-05-24 12:50:04 UTC --- --- Comment #5 from Martin Liška marxin.liska at gmail dot com 201 3-05-24 12:36:57 UTC --- Hello, I've just tried to build libreoffice with GNU ld (Linux/GNU Binutils) 2.23.52.0.2.20130423, latest version I am able to install on my gentoo ma chine, and the problem was reached. If it helps, I will checkout mainline bintuils and try it. Yes, please checkout the mainline binutils and if the problem is there try to produce preprocessed files to reproduce the bug. Thanks, Honza -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/15516] GNU LD is confused when linker plugin turns COMDAT symbol into static w/o renaming.
MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 html head base href=http://sourceware.org/bugzilla/; / /head body p div ba class=bz_bug_link bz_status_RESOLVED bz_closed title=RESOLVED WORKSFORME - GNU LD is confused when linker plugin turns COMDAT symbol into static w/o renaming. href=http://sourceware.org/bugzilla/show_bug.cgi?id=15516#c9;Comment # 9/a on a class=bz_bug_link bz_status_RESOLVED bz_closed title=RESOLVED WORKSFORME - GNU LD is confused when linker plugin turns COMDAT symbol into static w/o renaming. href=http://sourceware.org/bugzilla/show_bug.cgi?id=15516;bug 15516/a from span class=vcardhubicka#64;ucw.cz /span/b prespan class=quotegt; --- a href=show_bug.cgi?id=15516#c7Comment #7/a from Alan Modra lt;amodra at gmail dot comgt; 2013-05-24 14:37:29 UTC --- gt; Not preprocessed files, object files please. If this is a linker bug, I want gt; the inputs to the linker, including its invocation which you can see by adding gt; -v to the g++ command line./span Catch with object files and LTO is that they are GCC configuration specific. But lets try to get around with those. Honza/pre /div /p hr spanYou are receiving this mail because:/span ul liYou are on the CC list for the bug./li /ul /body /html ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/15516] GNU LD is confused when linker plugin turns COMDAT symbol into static w/o renaming.
http://sourceware.org/bugzilla/show_bug.cgi?id=15516 --- Comment #2 from hubicka at ucw dot cz 2013-05-22 16:44:43 UTC --- --- Comment #1 from Alan Modra amodra at gmail dot com 2013-05-22 16:24:05 UTC --- By turned into static do you mean that the typeinfo symbol in the real object is STB_LOCAL? typeinfo itself is not changed, just the symbol was previously common GCC localized it to static guided by RESOLVED_DEF_IRONLY resolution. For some reason this seem to break with the message above (that seems bogus, since it speaks of reference from plugin section) Honza -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/15300] AR/NM/GNU LD and Gold should issue a warning when used on objects with GCC/LLVM LTO data in it and no other symbols
http://sourceware.org/bugzilla/show_bug.cgi?id=15300 --- Comment #2 from hubicka at ucw dot cz 2013-03-24 18:02:40 UTC --- Or better still have the utilities load the plugin automatically. Yes, I think ideally the LTO capable compilers should install plugins into the binutils search path and binutils should simply load all available plugins and see what files they claims. That way wrappers won't be needed and mixed LTOs (with LTO objects from different compilers) has chance to work. Honza -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/15300] AR/NM/GNU LD and Gold should issue a warning when used on objects with GCC/LLVM LTO data in it and no other symbols
http://sourceware.org/bugzilla/show_bug.cgi?id=15300 --- Comment #3 from hubicka at ucw dot cz 2013-03-24 18:11:13 UTC --- Independently on that however I guess binutils should know to warn when the plugin mechanizm fails and LTO only object is being handled the normal way. It is really very common problem to run into and I think it is really hard to diagnoze for everyone except few people familiar with LTO machinery. Honza -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13244] GNU LD incorrectly complain about undefined hidden symbols with LTO
http://sourceware.org/bugzilla/show_bug.cgi?id=13244
--- Comment #2 from hubicka at ucw dot cz 2011-10-06 18:45:42 UTC ---
jh@evans:/abuild/jh/trunk-3/build-inst7/gcc cat t.c
extern __attribute__ ((visibility(hidden))) int fooblah;
static
do_nothing (int param)
{
if (param)
fooblah = 1;
}
main()
{
do_nothing (0);
}
jh@evans:/abuild/jh/trunk-3/build-inst7/gcc ./xgcc -B ./ -O2 t.c
-fno-early-inlining -flto -fuse-linker-plugin
jh@evans:/abuild/jh/trunk-3/build-inst7/gcc ./xgcc -B ./ -O2 t.c
-fno-early-inlining -flto -fuse-linker-plugin --shared
/abuild/jh/trunk-install/x86_64-unknown-linux-gnu/bin/ld: a.out: hidden symbol
`fooblah' isn't defined
/abuild/jh/trunk-install/x86_64-unknown-linux-gnu/bin/ld: final link failed:
Bad value
collect2: error: ld returned 1 exit status
With gold I get:
jh@evans:/abuild/jh/trunk-3/build-inst7/gcc ./xgcc -B ./ -O2 t.c
-fno-early-inlining -flto -fuse-linker-plugin --shared
jh@evans:/abuild/jh/trunk-3/build-inst7/gcc
because fooblah gets optimized out.
Honza
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13229] V2 of getsymbol linker plugin interface is not supported by GNU LD
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #12 from hubicka at ucw dot cz 2011-10-05 20:49:35 UTC ---
/* This is the prevailing definition of the symbol, with no
references from regular objects. It is only referenced from IR
code, but the symbol is exported and may be referenced from
a dynamic object (not seen at link time). */
LDPR_PREVAILING_DEF_IRONLY_EXP
It looks like it should be made dynamic since it is exported.
Do you have a stand-alone testcase for this?
What is causing the problem are LDPR_PREVAILING_DEF_IRONLY_EXP symbols
that are completely optimized out (i.e. not appearing in the output from
linker plugin, just in the LTO symbol table).
The follwing should work in C++
inline void test (void)
{
call_something();
}
void test2 (void)
{
test();
}
and compile with -flto -fuse-linker-plugin -fno-early-inlining -O3.
Late inliner wil linline test into test2, but test's symbol will still
appear in the symbol table (with V2 get_symbol API)
Honza
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/13245] PREVAILING_DEF reported too often.
http://sourceware.org/bugzilla/show_bug.cgi?id=13245 --- Comment #10 from hubicka at ucw dot cz 2011-10-04 09:17:43 UTC --- http://sourceware.org/bugzilla/show_bug.cgi?id=13245 --- Comment #9 from Cary Coutant ccoutant at google dot com 2011-10-03 21:50:21 UTC --- Here the function test is comdat both in libt.so and t2.so. In t2.so we would like to make it static because doing so improves dynamic linking time (i.e. the function in question don't need to be resolved at all). We can't want to do that in libt.so because that one is not LTOed. This would happen if linker returned PREVAILING_DEF_IRONLY_EXP for _Z4testv instead of PREVAILING_DEF. I think this is consistent with documentation of it - i.e. symbol is IRONLY within current DSO but exported. It does not matter much whether we know if libt.so will bind to it or not. So do you want the linker to ignore references from shared objects completely, or only if the reference is a (pre-empted) definition? I could make the former happen with the following patch: Hi, I am by far not confident in this area, but I personally don't see much difference for compiler to know whether the symbol will be bound by dynamic linker to other DSO or may be bound. So I guess ignoring symbols from shared libraries should work well, since they will all end up PREVAILING_DEF_IRONLY_EXP. Note that while looking at differences in resolution files in between gold and GNU LD I noticed that gold reports some symbols as UNDEF that are PREEMPTED_DYN for GNU LD. It is harmless, because internally GCC handles both prety much equally, but it seems wrong? Honza -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/13245] PREVAILING_DEF reported too often.
http://sourceware.org/bugzilla/show_bug.cgi?id=13245 --- Comment #12 from hubicka at ucw dot cz 2011-10-04 09:41:40 UTC --- http://sourceware.org/bugzilla/show_bug.cgi?id=13245 --- Comment #11 from rguenther at suse dot de 2011-10-04 09:24:22 UTC --- On Sun, 2 Oct 2011, Jan Hubicka wrote: Yes, it does solve the problem here (I have 8GB of RAM and used a large swapfile on my SSD. It took ~10 minutes to output all ltrans.o files). I am surprised it converge with 8GB of RAM at all... -fprofile-generate should set -fno-lto automatically IMHO. I suggested this at one point and richi didn't like it, forgot why. Thanks for looking into this! It is good to know this is the last bug WRT LTO linking of Mozilla ;) Well, it sounded like a hack. I'd rather have a way to force LTO profiling at least. Instrumentation at linktime is in my longer term TODO, but it will be fun - we will need to pickle CFG at compile time and with -fprofile-generate decide on placement of instrumentation at WPA time making the actual modifications at ltrans time. It is not that hard to do, but needs some work - i.e. cleanup what gcov has already, because gcov has pretty much all needed, but not readily useable within compiler and not with the fancier features like automatic correction. Also if we get variant of LIPO into mainline, we will be stuck with the instrumentation at compile time too. Honza -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/13245] PREVAILING_DEF reported too often.
http://sourceware.org/bugzilla/show_bug.cgi?id=13245 --- Comment #3 from hubicka at ucw dot cz 2011-10-02 10:10:58 UTC --- I cannot reproduce this issue: Sorry, it is because mainline still contains the hack for COMDAT handling (I diseabled it in my tree to verify that new IRONLY solution works). You need to extend the testcases to take address of the inline function so the hack is ineffective. Honza -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/13245] PREVAILING_DEF reported too often.
http://sourceware.org/bugzilla/show_bug.cgi?id=13245 --- Comment #4 from hubicka at ucw dot cz 2011-10-02 10:48:55 UTC --- Sorry, it is because mainline still contains the hack for COMDAT handling (I diseabled it in my tree to verify that new IRONLY solution works). You need to extend the testcases to take address of the inline function so the hack is ineffective. Actually adding address would just convolute the testcase in a way that the intended optimization would be impossible (we can not unshare the two comdats since we do not know if the oher library takes address of test, too). Probably easiest way to reproduce is to update to today tree (you need v2 plugin API support I just comitted) and disable the comdat hack. The problem hits without comdat hack, too (like is the case of Mozilla with -fprofile-generate) but it is more difficult to produce a testcase. BTW I am starting to wonder by linker results in PREVAILING_DEF at all. When I know Iam going to link with a shared library that exports the comdat, I can just optimize it out. So at least w/o LTO it would make sense for me if linker just preemted it to the dynamic linking then. Honza Index: lto-streamer-out.c === --- lto-streamer-out.c(revision 179423) +++ lto-streamer-out.c(working copy) @@ -1396,7 +1396,7 @@ produce_symtab (struct output_block *ob, if (DECL_EXTERNAL (node-decl)) continue; if (DECL_COMDAT (node-decl) - cgraph_comdat_can_be_unshared_p (node)) + cgraph_comdat_can_be_unshared_p (node) 0) continue; if ((node-alias !node-thunk.alias) || node-global.inlined_to) continue; @@ -1408,7 +1408,7 @@ produce_symtab (struct output_block *ob, if (!DECL_EXTERNAL (node-decl)) continue; if (DECL_COMDAT (node-decl) - cgraph_comdat_can_be_unshared_p (node)) + cgraph_comdat_can_be_unshared_p (node) 0) continue; if ((node-alias !node-thunk.alias) || node-global.inlined_to) continue; @@ -1427,7 +1427,7 @@ produce_symtab (struct output_block *ob, if (DECL_COMDAT (vnode-decl) !vnode-force_output vnode-finalized - DECL_VIRTUAL_P (vnode-decl)) + DECL_VIRTUAL_P (vnode-decl) 0) continue; if (vnode-alias !vnode-alias_of) continue; @@ -1441,7 +1441,7 @@ produce_symtab (struct output_block *ob, if (DECL_COMDAT (vnode-decl) !vnode-force_output vnode-finalized - DECL_VIRTUAL_P (vnode-decl)) + DECL_VIRTUAL_P (vnode-decl) 0) continue; if (vnode-alias !vnode-alias_of) continue; -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/13245] PREVAILING_DEF reported too often.
http://sourceware.org/bugzilla/show_bug.cgi?id=13245
--- Comment #6 from hubicka at ucw dot cz 2011-10-02 15:22:07 UTC ---
http://sourceware.org/bugzilla/show_bug.cgi?id=13245
--- Comment #5 from Octoploid cryptooctoploid at gmail dot com 2011-10-02
13:01:38 UTC ---
What about the following naive patch?
diff --git a/gold/plugin.cc b/gold/plugin.cc
index b5880a1..d999254 100644
--- a/gold/plugin.cc
+++ b/gold/plugin.cc
@@ -889,10 +889,10 @@ Pluginobj::get_symbol_resolution_info(int nsyms,
res = LDPR_RESOLVED_EXEC;
else if (lsym-object()-pluginobj() == this)
{
- if (is_referenced_from_outside(lsym))
- res = LDPR_PREVAILING_DEF;
- else if (is_visible_from_outside(lsym))
+ if (is_visible_from_outside(lsym))
res = ldpr_prevailing_def_ironly_exp;
+ else if (is_referenced_from_outside(lsym))
+ res = LDPR_PREVAILING_DEF;
I think the condiitonals would need to be swapped at least. When the symbol is
used from .o file it has
to be LDPR_PREVAILING_DEF no matter if it is exported or not.
It also survived bootstrap-lto of gcc and an -flto -fno-fat-lto-objects
build
of Firefox.
Cool! If you happen to have a lot of memory (15GB), you may try if it solves
the -fprofile-generate -flto
problem.
In meantime I suceeded building FDO+LTO firefox with -fprofile-generate
-fno-lto train run (that makes more sense
anyway, I am trying to debug the other just to be sure that there are no more
problems in this area)
Honza
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/13245] PREVAILING_DEF reported too often.
http://sourceware.org/bugzilla/show_bug.cgi?id=13245 --- Comment #8 from hubicka at ucw dot cz 2011-10-02 20:50:50 UTC --- Yes, it does solve the problem here (I have 8GB of RAM and used a large swapfile on my SSD. It took ~10 minutes to output all ltrans.o files). I am surprised it converge with 8GB of RAM at all... -fprofile-generate should set -fno-lto automatically IMHO. I suggested this at one point and richi didn't like it, forgot why. Thanks for looking into this! It is good to know this is the last bug WRT LTO linking of Mozilla ;) Honza -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13229] V2 of getsymbol linker plugin interface is not supported by GNU LD
http://sourceware.org/bugzilla/show_bug.cgi?id=13229 --- Comment #6 from hubicka at ucw dot cz 2011-10-01 13:14:11 UTC --- I guess Gold is just tolerant here and I would say that GNU LD should be too. I will work out how this symbol appears in the symbol table. Filled in as PR13244. Honza -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13229] V2 of getsymbol linker plugin interface is not supported by GNU LD
http://sourceware.org/bugzilla/show_bug.cgi?id=13229 --- Comment #7 from hubicka at ucw dot cz 2011-10-01 13:50:13 UTC --- http://sourceware.org/bugzilla/show_bug.cgi?id=13229 --- Comment #6 from hubicka at ucw dot cz 2011-10-01 13:14:11 UTC --- I guess Gold is just tolerant here and I would say that GNU LD should be too. I will work out how this symbol appears in the symbol table. Filled in as PR13244. And built Mozilla with patch solving PR13244 at GCC side. libxul builds and it is about 2% bigger than gold variant. I guess it is the gold's removal of equivalent functions. So the patch works as expected. What is the minimal binutils version supporting the V2 API? (I would like to add info into gcc changes.html) Honza -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13229] V2 of getsymbol linker plugin interface is not supported by GNU LD
http://sourceware.org/bugzilla/show_bug.cgi?id=13229 --- Comment #8 from hubicka at ucw dot cz 2011-10-01 14:23:01 UTC --- Hi, the following is a diff from GNU LD to Gold build. I previously complained about RESOLVED_DYN/UNDEF difference. It is harmless since internall for GCC it does not make difference if something is undef or resolved externally. However I am concerned about: -2178 cf6ad577 PREVAILING_DEF NSModule +2178 cf6ad577 PREVAILING_DEF_IRONLY_EXP NSModule I would expect that both implementations ought to agree on this one way or another? What makes build to fail is 2448 9647e1fd PREVAILING_DEF _ZTV17gfxUnknownSurface _ZTV17gfxUnknownSurface then reffer to 1091 9647e1fd UNDEF _ZN11gfxASurface13BeginPrintingERK9nsAStringS2_ I think source is incorrect and rely on fact that all references to _ZTV17gfxUnknownSurface are optimized, but still we ought to be able to do so given that we do so even at -O0. Honza --- ./-lm.res2011-10-01 15:58:24.0 +0200 +++ a.res2011-10-01 15:58:15.0 +0200 @@ -1,5 +1,5 @@ 27 -nsModule.o 75 +/abuild/jh/build-mozilla-new14-gnu-ld/browser/components/build/nsModule.o 75 324 cf6ad577 PREVAILING_DEF_IRONLY _ZN12nsAutoRefCntC2Ev 344 cf6ad577 PREVAILING_DEF_IRONLY _ZN12nsAutoRefCntC1Ev 349 cf6ad577 PREVAILING_DEF_IRONLY _ZN13nsCOMPtr_baseC2EP11nsISupports @@ -48,7 +48,7 @@ 1714 cf6ad577 PREVAILING_DEF_IRONLY _ZN8nsCOMPtrI25nsIPrivateBrowsingServiceEC2Ev 1723 cf6ad577 PREVAILING_DEF_IRONLY _ZN8nsCOMPtrI25nsIPrivateBrowsingServiceEC1Ev 1727 cf6ad577 RESOLVED_IR _ZN7mozilla7browser15AboutRedirector6CreateEP11nsISupportsRK4nsIDPPv -225 cf6ad577 RESOLVED_DYN __cxa_pure_virtual +225 cf6ad577 UNDEF __cxa_pure_virtual 1737 cf6ad577 RESOLVED_DYN moz_xmalloc 1754 cf6ad577 RESOLVED_IR _ZN22nsOperaProfileMigratorC1Ev 816 cf6ad577 RESOLVED_IR _ZN17nsProfileMigrator6AddRefEv @@ -68,14 +68,14 @@ 1197 cf6ad577 PREVAILING_DEF_IRONLY _ZTV17nsIContentSniffer 1223 cf6ad577 PREVAILING_DEF_IRONLY _ZTV18nsIRequestObserver 1250 cf6ad577 PREVAILING_DEF_IRONLY _ZTV17nsIStreamListener -2178 cf6ad577 PREVAILING_DEF NSModule +2178 cf6ad577 PREVAILING_DEF_IRONLY_EXP NSModule 792 cf6ad577 RESOLVED_IR _ZTV17nsProfileMigrator 1075 cf6ad577 RESOLVED_IR _ZTVN7mozilla7browser17DirectoryProviderE 1559 cf6ad577 RESOLVED_IR _ZTV31nsPrivateBrowsingServiceWrapper 498 cf6ad577 RESOLVED_IR _ZTV19nsGNOMEShellService 904 cf6ad577 RESOLVED_IR _ZTVN7mozilla7browser15AboutRedirectorE 1284 cf6ad577 RESOLVED_IR _ZTV13nsFeedSniffer -../feeds/src/nsFeedSniffer.o 117 +/abuild/jh/build-mozilla-new14-gnu-ld/browser/components/build/../feeds/src/nsFeedSniffer.o 117 561 78bede03 PREVAILING_DEF_IRONLY _ZN13nsFeedSniffer6AddRefEv 674 78bede03 PREVAILING_DEF_IRONLY _ZThn8_N13nsFeedSniffer6AddRefEv 612 78bede03 PREVAILING_DEF_IRONLY _ZN13nsFeedSniffer14OnStartRequestEP10nsIRequestP11nsISupports @@ -164,7 +164,7 @@ 1453 78bede03 PREVAILING_DEF_IRONLY _ZN15nsGetterAddRefsI6nsIURIEcvPPS0_Ev 590 78bede03 PREVAILING_DEF_IRONLY _ZN13nsFeedSniffer22GetMIMETypeFromContentEP10nsIRequestPKhjR10nsACString 735 78bede03 RESOLVED_IR _ZN10nsACString17DefaultComparatorEPKcS1_j -1140 78bede03 RESOLVED_DYN __cxa_pure_virtual +1140 78bede03 UNDEF __cxa_pure_virtual 1460 78bede03 RESOLVED_IR _ZNK10nsACString12BeginReadingEv 1469 78bede03 RESOLVED_IR _ZNK10nsACString4FindEPKcPFiS1_S1_jE 1487 78bede03 RESOLVED_IR _Z16NS_TableDrivenQIPvPK12QITableEntryRK4nsIDPS_ @@ -193,7 +193,7 @@ 1719 78bede03 PREVAILING_DEF_IRONLY _ZN18nsIRequestObserver11COMTypeInfoIiE4kIIDE 1735 78bede03 PREVAILING_DEF_IRONLY _ZN11nsISupports11COMTypeInfoIiE4kIIDE 1172 78bede03 RESOLVED_IR _ZTV28nsCreateInstanceByContractID -../privatebrowsing/src/nsPrivateBrowsingServiceWrapper.o 50 +/abuild/jh/build-mozilla-new14-gnu-ld/browser/components/build/../privatebrowsing/src/nsPrivateBrowsingServiceWrapper.o 50 384 313f401 PREVAILING_DEF_IRONLY _ZN31nsPrivateBrowsingServiceWrapper6AddRefEv 513 313f401 PREVAILING_DEF_IRONLY _ZThn8_N31nsPrivateBrowsingServiceWrapper6AddRefEv 366 313f401 PREVAILING_DEF_IRONLY _ZN31nsPrivateBrowsingServiceWrapper14QueryInterfaceERK4nsIDPPv @@ -244,7 +244,7 @@ 896 313f401 PREVAILING_DEF_IRONLY _ZN17nsIJSContextStack11COMTypeInfoIiE4kIIDE 870 313f401 PREVAILING_DEF_IRONLY _ZN11nsIObserver11COMTypeInfoIiE4kIIDE 888 313f401 PREEMPTED_IR _ZN11nsISupports11COMTypeInfoIiE4kIIDE -../about/AboutRedirector.o 88 +/abuild/jh/build-mozilla-new14-gnu-ld/browser/components/build/../about/AboutRedirector.o 88 551 468bb758 PREEMPTED_IR _ZN7mozilla7browser15AboutRedirectorD2Ev 412 468bb758 PREEMPTED_IR _ZN7mozilla7browser15AboutRedirectorD1Ev 316 468bb758 PREVAILING_DEF_IRONLY _ZN7mozilla7browser15AboutRedirector6AddRefEv @@ -311,7 +311,7 @@ 991 468bb758 PREVAILING_DEF_IRONLY _ZN15nsGetterAddRefsI12nsIPrincipalEcvPPS0_Ev 379 468bb758 PREVAILING_DEF_IRONLY _ZN7mozilla7browser15AboutRedirector10NewChannelEP6nsIURIPP10nsIChannel 539 468bb758 RESOLVED_IR _ZN10nsACString17DefaultComparatorEPKcS1_j -244 468bb758
[Bug ld/13229] V2 of getsymbol linker plugin interface is not supported by GNU LD
http://sourceware.org/bugzilla/show_bug.cgi?id=13229 --- Comment #4 from hubicka at ucw dot cz 2011-09-30 16:31:05 UTC --- Hi, I can build Mozilla with GNU LD with resulting binary being about the same size as gold's so it seems to be all fine. Also the TLS problems are gone. Thanks a lot! Honza -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13229] V2 of getsymbol linker plugin interface is not supported by GNU LD
http://sourceware.org/bugzilla/show_bug.cgi?id=13229 --- Comment #5 from hubicka at ucw dot cz 2011-09-30 17:10:55 UTC --- Hi, I can build Mozilla with GNU LD with resulting binary being about the same size as gold's so it seems to be all fine. Also the TLS problems are gone. Actually I got fooled by gold sitting earlier on the search path. Link still fails with the following error: /abuild/jh/trunk-install/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../x86_64-unknown-linux-gnu/bin/ld: libxul.so: hidden symbol `_mm_load_si128' isn't defined /abuild/jh/trunk-install/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../x86_64-unknown-linux-gnu/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status It is curious becaue _mm_load_si128 is always inline and it should not be used. Also it is not used by any of the linker plugin output, it however appears in the original symbol tables as undefined symbol: jh@evans:/abuild/jh/build-mozilla-new14/toolkit/library grep _mm_load_si128 *.s jh@evans:/abuild/jh/build-mozilla-new14/toolkit/library grep _mm_load_si128 ./-lm.res 172 6129b4c0 UNDEF _Z14_mm_load_si128PKU8__vectorx 178 590a071d UNDEF _Z14_mm_load_si128PKU8__vectorx 557 7620c055 UNDEF _Z14_mm_load_si128PKU8__vectorx 974 314cd963 UNDEF _mm_load_si128 I guess Gold is just tolerant here and I would say that GNU LD should be too. I will work out how this symbol appears in the symbol table. IRONLY/IRONLY_EXP split seems to work as expected, so this is probably unrelated problem. Honza Thanks a lot! Honza -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
