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-
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)
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
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
I also need /lib/libc.so.6.1 and /usr/lib/libc_nonshared.a.
I also need ld-linux.so.2.
The slowdown is caused by
elf64_alpha_size_rela_got_1 is called many many many times.
(In reply to comment #13)
> The slowdown is caused by
> 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.
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
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
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.
H.-H.-Meier-Allee 63, D-28213 Bremen
> -----Original Message-----
> From: hjl at lucon dot org [mailto:firstname.lastname@example.org]
> Sent: Monday, June 18, 2007 8:58 PM
> To: email@example.com
> 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
> help? How does the binutils in CVS work now?
> What |Removed |Added
> Status|NEW |WAITING
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.