Okay yet another post writing about the gold linker. I finally checked out what I wanted: indeed gold does not do the collapse of duplicated substring: my script reports this:
flame@enterprise ruby-elf % ruby -Ilib tools/assess_duplicate_save.rb /usr/lib/libbonobo-2.so
/usr/lib/libbonobo-2.so: current size 36369, full size 44794 difference 8425
flame@enterprise ruby-elf % ruby -Ilib tools/assess_duplicate_save.rb /usr/lib/libbonobo-2.so
/usr/lib/libbonobo-2.so: current size 44860, full size 44860 difference 0
I wonder about the size difference between the original and the new one, I actually didn’t expect a bigger size than the one my script reported. I suppose it could be that my scripts tends to count full duplicated strings just once. After all, finding full duplicates is a lot easier than substrings, and quite faster. Of course, it’s also true that you cannot have duplicates in the symbols’ names, you can only have duplicates in sonames, NEEDED entries and runpaths.
But for anybody who would like to try gold after Bernard’s post, pay attention! The binaries it generates seems to be prone to TEXTRELs, which is quite bad.
* QA Notice: The following files contain runtime text relocations
* Text relocations force the dynamic linker to perform extra
* work at startup, waste system resources, and may pose a security
* risk. On some architectures, the code may not even function
* properly, if at all.
* For more information, see http://hardened.gentoo.org/pic-fix-guide.xml
* Please include this file in your report:
* /var/tmp/portage/gnome-base/libbonobo-2.22.0/temp/scanelf-textrel.log
* TEXTREL usr/bin/activation-client
TEXTREL usr/bin/echo-client-2
TEXTREL usr/bin/bonobo-activation-run-query
TEXTREL usr/libexec/bonobo-activation-server
TEXTREL usr/sbin/bonobo-activation-sysconf
TEXTREL usr/lib64/bonobo-2.0/samples/bonobo-echo-2
As the warning tells you, the textrel will make the startup of programs slower, it will make the program waste memory, and it will not work properly with Hardened kernels.
Also, now that I look at the strings that are in the .dynstr of the gold-linked libbonobo-2 and not in the old version, it seems like gold introduces two extra NEEDED entries (libgcc_s.so.1 and ld-linux, the runtime linker), which I’m unsure where they come from, nor why they should be in there. There is also an extra end symbol that is not generated by standard ld. I don’t know why “.libs/libbonobo-2.so.0.0.0” is saved, I can’t see it referenced in readelf -d output, I’ll ahve to dig up if it’s actually used at all.
As you can guess, gold is really not ready for primetime at all. Also, I start to wonder how much of gold improved performance is actually related to collapsing the duplicate sub-strings.
Sincerely, I start to think that a lot of that performance gain is due to the sub-string collapsing, I tried to think of it in multiple ways, and that particular feature is overly complex for modern systems. And the fact that gold has its biggest performance improvement with C++, where that feature is always useless (you don’t have a common ending sub-string on C++ symbols either prefixing or suffixing them), makes me think that a lot of the performance improvement is laying there, rather than on the other re-writing efforts (C++ usage and ELF-only linker).
I think I’ll see to cut out some time to hack at binutils and see if I can disable the collapse through an option, which would be quite nice.
gold will compress string tables if you give it the -O2 option. Compressing string tables can increase link time about 25% the last time I tested it (i.e., this is part of the speedup, but not the main cause).To make GNU ld *not* compress string tables, edit _bfd_elf_strtab_finalize in bfd/elf-strtab.c.Unnecessary TEXTREL entries are obviously a bug–could you send a bug report to binutils@sourceware.org?Thanks for trying gold–it will only get better if people try it and report the problems.
It certainly comes down to ones expectations and needs, but from my point of view, gold is already pretty neat and useful: For example, linking the fgfs binary from the FlightGear project (mostly C++ code with lots of dependencies to static libs with even more C++ symbols) takes now only 5-6 seconds flat, while it used to take easily 30+ seconds before, or even longer.Gold is another important step in reducing unnecessary interruptions while programming, there’s often so much redundancy going on when compiling and linking executables, it’s really refreshing to see a tool actually perform rather well in comparison with its alternatives.Now, what’d be awesome would be if gcc had support for incremental compilation, so that it could largely reuse previously compiled code, while just recompiling functions that were modified in the source code or that need to be recompiled due to sequential dependencies to modified code.I am sure that gold in combination with support for incremental compiling in gcc would make it much more viable to bootstrap large C++ projects, such as Mozilla/Firefox, KDE etc.