Bug 1543

Summary: [regression] LD very slow especially when linking C++ object files on alpha
Product: binutils Reporter: Uwe Schindler <uwe>
Component: ldAssignee: unassigned
Status: RESOLVED FIXED    
Severity: normal CC: alenhar2, bug-binutils, hjl.tools, kloeri, rezso, rth, stefaan.deroeck
Priority: P2    
Version: 2.17   
Target Milestone: ---   
Host: alpha-linux Target: alpha-linux
Build: alpha-linux Last reconfirmed:

Description Uwe Schindler 2005-10-25 19:03:19 UTC
This bug occurred some time after the release of 2.16.1. Because this version 
had a bug that makes it impossible to link files generated by gcc-4.0 for the 
alpha platform, debian unstable contains a newer version from CVS.

When linking especially C++ files generated by GCC 4.0 (not tested with earlier 
versions of GCC) ld uses about 100% CPU and takes for a simple executable of 
about 4 MBytes size about 2 hours (Alphaststion 500/500). We decided to run 
oprofile on ld and it is spending all it's time in 
bfd_elf_size_dynsym_hash_dynstr. At this point 99.9998% of time is being spent 
in that function.

I wrote this bug report because I do not exspect the debian developers to fix 
that for a rarely used platform like alpha.

See the debian bug report for more information: http://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=334766
Comment 1 Andrew Lenharth 2005-10-25 20:34:21 UTC
ok, 150 minutes into a link that use to take 15 minutes, here is a quick profile:

opreport -l /usr/local/bin/ld
CPU: Alpha EV67, speed 666.667 MHz (estimated)
Counted CYCLES events (Total cycles) with a unit mask of 0x00 (No unit mask)
count 100000
samples  %        symbol name
6614073  28.9892  elf64_alpha_size_rela_got_1
5045180  22.1128  bfd_hash_traverse
3356753  14.7125  elf64_alpha_calc_got_offsets_for_symbol
2907533  12.7436  _bfd_elf_dynamic_symbol_p
1722520   7.5497  bfd_elf_size_dynsym_hash_dynstr
1546409   6.7778  elf64_alpha_size_plt_section_1
619400    2.7148  elf64_alpha_size_got_sections
417174    1.8285  alpha_dynamic_entries_for_reloc
325541    1.4268  elf64_alpha_size_rela_got_section
135745    0.5950  bfd_get_section_by_name
96504     0.4230  bfd_hash_lookup
Comment 2 H.J. Lu 2005-10-25 23:24:30 UTC
Can you provide a suitable testcase for cross alpha linker?
Comment 3 Uwe Schindler 2005-10-26 19:17:15 UTC
I will try to extract some .o files that can be linked together and will 
provide them to you. My current project needs many external libs, so it is not 
simple to give you samples.

The bug affects ALL links when C++ code is involved or a lot of symbols are 
involved, so it would be simple to generate a test case with some source code 
from a C++ project, if you have an alpha machine.

If you are interested, I could give you access to the alpha machine and you can 
debug "ld" natively on the platform.
Comment 4 H.J. Lu 2005-10-27 16:33:57 UTC
Please provide binaries for a cross linker if you want me to take a look.
Comment 5 Andrew Lenharth 2005-10-27 20:36:50 UTC
I have placed a test case at http://www.lenharth.org/~andrewl/bug.tgz
The file cmdline.txt contains the command line used to link (-L flags replaced
and libraries moved to one directory).  There are excess libraries in the
archive since it was easier to copy them all. All the gcc libs are included, so
I think I have included everything you need to do tests.  This isn't the worst
case I have, this only takes about 35 minutes (use to take less than 3).  I can
arrange others.
Comment 6 Andrew Lenharth 2005-10-27 21:06:25 UTC
Just as a clarification, the test case I sent eventually (after 45 minutes) dies
with an error, but that should be irrelevent to the usefulness of the test case.
Comment 7 H.J. Lu 2005-10-27 22:11:40 UTC
Please provide libpthread.so.0 and libpthread_nonshared.a.
Comment 8 Andrew Lenharth 2005-10-27 23:23:03 UTC
the archive is updated with the requested files.  libpthread.so.0 is a symlink
for libpthread-0.10.so.
Comment 9 H.J. Lu 2005-10-28 15:32:41 UTC
I also need  /lib/libc.so.6.1 and /usr/lib/libc_nonshared.a.
Comment 10 Andrew Lenharth 2005-10-28 16:11:45 UTC
Updated again.
Comment 11 H.J. Lu 2005-10-28 17:00:07 UTC
I also need ld-linux.so.2.
Comment 12 Andrew Lenharth 2005-10-28 17:10:50 UTC
updated.
Comment 13 H.J. Lu 2005-10-28 22:04:49 UTC
The slowdown is caused by

http://sourceware.org/ml/binutils/2005-05/msg00736.html

elf64_alpha_size_rela_got_1 is called many many many times.
Comment 14 Falk Hueffner 2006-05-07 16:22:34 UTC
(In reply to comment #13)
> The slowdown is caused by
> 
> http://sourceware.org/ml/binutils/2005-05/msg00736.html
> 
> elf64_alpha_size_rela_got_1 is called many many many times.

I would really like to see this fixed, at the moment for example mozilla takes
3 hours to link. Does anybody have a suggestion how to go about this?
Comment 15 rth@redhat.com 2006-05-08 16:00:48 UTC
Subject: Re:  [regression] LD very slow especially when linking C++ object files on alpha

On Sun, May 07, 2006 at 04:22:38PM -0000, falk at debian dot org wrote:
> I would really like to see this fixed, at the moment for example mozilla takes
> 3 hours to link. Does anybody have a suggestion how to go about this?

Relaxation needs a new hook, so that we can re-layout the got
*once* at the end of a pass through all sections.


r~
Comment 16 Andrew Lenharth 2006-05-08 17:39:02 UTC
I will be happy to lend what assistance I can.  LLVM takes 36 hours to link with
this bug.  That is too long to be usable for development and nightly testing.
Comment 17 Stefaan 2006-12-23 10:03:45 UTC
Same symptoms on an alpha, also noticed while trying to build mozilla-firefox/thunderbird.  
Comment 18 Balint Cristian 2007-01-17 04:57:49 UTC
It's a mess. if i try to build latest gcc with libgcj enabled it will take 
_forever_.

any update on issue ? workaround ?
Comment 19 Balint Cristian 2007-01-17 13:47:54 UTC
As a fine temporary workaround:

use ld --no-relax, or pass compiler with -Wl,--no-relax or patch --no-relax to 
default / --relax as optional and everything turn to be fine after :-)

firefox links in /layout now in 11 minutes instead of 4:30 hour, and anyway i 
think we could live without relax.

I bootstrapped to alphacore [fedora-devel] this way with latest CVS pool of 
glibc/gcc-4.1.2/binutils and everything seems fine.



Comment 20 H.J. Lu 2007-06-18 18:58:02 UTC
Does this patch

http://sourceware.org/ml/binutils/2007-04/msg00084.html

help? How does the binutils in CVS work now?
Comment 21 Uwe Schindler 2007-06-25 21:59:29 UTC
Subject: RE:  [regression] LD very slow especially when linking C++ object files on alpha

Debian Testing binutils contains this patch since a view weeks (I checked
this in the source). I tried to build the affected program again, linking
seems to be fast now.

So the bugs seems to be fixed now.

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de

> -----Original Message-----
> From: hjl at lucon dot org [mailto:sourceware-bugzilla@sourceware.org]
> Sent: Monday, June 18, 2007 8:58 PM
> To: uwe@thetaphi.de
> Subject: [Bug ld/1543] [regression] LD very slow especially when linking
> C++ object files on alpha
> 
> 
> ------- Additional Comments From hjl at lucon dot org  2007-06-18 18:58 --
> -----
> Does this patch
> 
> http://sourceware.org/ml/binutils/2007-04/msg00084.html
> 
> help? How does the binutils in CVS work now?
> 
> --
>            What    |Removed                     |Added
> --------------------------------------------------------------------------
> --
>              Status|NEW                         |WAITING
> 
> 
> http://sourceware.org/bugzilla/show_bug.cgi?id=1543
> 
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.

Comment 22 H.J. Lu 2007-06-25 23:11:41 UTC
Fixed.