Bug 3111 - LD very slow linking object files containing dwarf2 symbols
Summary: LD very slow linking object files containing dwarf2 symbols
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.18
: P2 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
: 3321 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-08-23 15:26 UTC by Mathias Doreille
Modified: 2014-05-28 19:45 UTC (History)
5 users (show)

See Also:
Host: x86_64-unknown-linux-gnu
Target:
Build:
Last reconfirmed:


Attachments
gprof execution profile of ld (38.80 KB, text/plain)
2006-08-23 15:35 UTC, Mathias Doreille
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mathias Doreille 2006-08-23 15:26:41 UTC
This bug occurs with the binutils-060823 snapshot and  binutils-2.16.91.0.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-2.17.50.0.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
2.17.50.0.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 2.17.50.0.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 2.17.50.0.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 13 Alan Modra 2006-11-17 14:02:34 UTC
Caching implemented in http://sources.redhat.com/ml/binutils/2006-11/msg00190.html
Comment 14 Jackie Rosen 2014-02-16 19:34:40 UTC Comment hidden (spam)