Sourceware Bugzilla – Full Text Bug Listing
|Summary:||LD very slow linking object files containing dwarf2 symbols|
|Product:||binutils||Reporter:||Mathias Doreille <doreille>|
|Severity:||normal||CC:||bug-binutils, doreille, hjl.tools, rodsoft, Scott|
|Attachments:||gprof execution profile of ld|
Description Mathias Doreille 2006-08-23 15:26:41 UTC
This bug occurs with the binutils-060823 snapshot and binutils-18.104.22.168.6-5 (fedora-5) on both x86-64 and i386 architectures. It do not occur with binutils-2.15.94 (fedora-4). When linking C++ files compiled by GCC 4.1.1 with the -g option ld take 3 minutes to link . Without the -g option the link time was 5 seconds. The obtained shared library has 17 MBytes size without debugging symbols and 59 MBytes size with debugging symbols.
Comment 1 Mathias Doreille 2006-08-23 15:35:04 UTC
Created attachment 1243 [details] gprof execution profile of ld This is the gprof call graph profile data of ld (binutils-060823 ) linking the files with the dwarf2 symbols.
Comment 2 H.J. Lu 2006-08-25 14:52:38 UTC
Please try the current Linux binutils at http://www.kernel.org/pub/linux/devel/binutils/ and follow its release note closely.
Comment 3 Mathias Doreille 2006-08-25 16:40:29 UTC
I have installed the latest binary rpm package binutils-22.214.171.124.3-1.x86_64.rpm. With this version, the link time was 6m20.613s with the debugging symbols. Without the debugging symbols, the link time was 4.369s.
Comment 4 H.J. Lu 2006-08-25 16:44:12 UTC
Are you sure that you used the correct linker?
Comment 5 H.J. Lu 2006-08-25 16:51:08 UTC
Is this the same bug as in commect #9 in PR 2342: http://sources.redhat.com/bugzilla/show_bug.cgi?id=2342#c9
Comment 6 Mathias Doreille 2006-08-29 18:01:33 UTC
I think this bug is the same as the one in comment #9 of PR 2342. With binutils 126.96.36.199.3 (linux patch applied) and the given test case slowld.tar.gz the link time was 2m54.853s. After removing the debugging symbols with 'strip -g' the link time become 6.386s. I have another test case at ftp://www.smr.ch/pub/smr/read/slow_ld_testcase.tar.bz2 with seven elf64 object files where the link time was 1m7.316s with debugging symbols but 0.926s after a 'strip -g *.o'.
Comment 7 H.J. Lu 2006-08-29 23:06:04 UTC
They are 2 different problems. With the previous patch, I got 18 sections: time g++ -B/export/home/hjl/usr/bin/ -g -o ff3d trapFPE.o main.o FFThread.o StaticCenter.o \ language/libfflanguage.a solver/libffsolve.a \ language/libpovlanguage.a geometry/libffgeometry.a \ algebra/libffalgebra.a utils/libffutils.a -pthread FFThread.o: In function `FFThread::run()': /space/rguenther/src/c++bench/ff3d/FFThread.cpp:79: undefined reference to `__cxa_get_exception_ptr' StaticCenter.o: In function `LagrangianFiniteElement': ./solver/LagrangianFiniteElement.hpp:365: undefined reference to `__cxa_get_exception_ptr' ./solver/LagrangianFiniteElement.hpp:365: undefined reference to `__cxa_get_exception_ptr' ./solver/LagrangianFiniteElement.hpp:365: undefined reference to `__cxa_get_exception_ptr' ./solver/LagrangianFiniteElement.hpp:365: undefined reference to `__cxa_get_exception_ptr' StaticCenter.o:./solver/LagrangianFiniteElement.hpp:365: more undefined references to `__cxa_get_exception_ptr' follow collect2: ld returned 1 exit status Command exited with non-zero status 1 18.32user 1.60system 0:19.92elapsed 100%CPU The other problem is the N^2 issue mentioned in the previous bug report. It is the same as this one. I posted a patch at http://sourceware.org/ml/binutils/2006-08/msg00334.html
Comment 8 Rafael Ávila de Espíndola 2006-09-06 13:53:06 UTC
I have done some testing on this problem: link time just before http://sourceware.org/ml/binutils-cvs/2004-07/msg00124.html: real 0m8.783s user 0m8.049s sys 0m0.628s After: real 13m49.449s user 12m57.109s sys 0m8.897s current CVS: real 3m52.577s user 3m43.602s sys 0m8.665s current CVS + proposed patch: real 0m5.780s user 0m3.528s sys 0m0.596s Why the proposed patch wasn't committed? I am not familiar with binutils, but maybe I can help.
Comment 9 Rodolfo Lima 2006-10-03 10:51:24 UTC
ld´s changelog of 188.8.131.52.3 (or 4...) binutils says that this patch is applied, but in fact it isn´t, as this version is still affected by this bug. The patch can´t be seen in cvs either. IMO this is a major bug, the difference between linking with and without -g is absurd... we can get from 6min to 30s just by removing -g... Someone please commit the patch to cvs please.
Comment 10 H.J. Lu 2006-10-03 12:50:25 UTC
Please follow the release note of the Linux binutils 184.108.40.206.5. You need to apply patches in patches PROPERLY. Or you should use binary rpmes.
Comment 11 H.J. Lu 2006-10-16 21:49:43 UTC
*** Bug 3321 has been marked as a duplicate of this bug. ***
Comment 12 H.J. Lu 2006-10-30 23:44:00 UTC
http://sourceware.org/ml/binutils/2006-08/msg00334.html is checked in. The maining one is http://sourceware.org/ml/binutils/2006-04/msg00329.html
Comment 13 Alan Modra 2006-11-17 14:02:34 UTC
Caching implemented in http://sources.redhat.com/ml/binutils/2006-11/msg00190.html