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
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
Can you provide a suitable testcase for cross alpha linker?
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.
Please provide binaries for a cross linker if you want me to take a look.
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.
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.
Please provide libpthread.so.0 and libpthread_nonshared.a.
the archive is updated with the requested files. libpthread.so.0 is a symlink for libpthread-0.10.so.
I also need /lib/libc.so.6.1 and /usr/lib/libc_nonshared.a.
Updated again.
I also need ld-linux.so.2.
updated.
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.
(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?
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~
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.
Same symptoms on an alpha, also noticed while trying to build mozilla-firefox/thunderbird.
It's a mess. if i try to build latest gcc with libgcj enabled it will take _forever_. any update on issue ? workaround ?
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.
Does this patch http://sourceware.org/ml/binutils/2007-04/msg00084.html help? How does the binutils in CVS work now?
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.
Fixed.