This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Very slow link times on debug versions of C++ program on x86_64. Includes oprofile of ld...


Hi all,

I've recently upgraded my machine here to an x86_64 box running Fedora
Core 6 (7 came out a week after I installed doh!).  I have a largish C++
program that I compile in both a release (-O3 -DNDEBUG) and debug (-O0
-ggdb3) versions that uses a lot of templates and stuff.  Linking the
release one is pretty quick...on the order of 10-20 seconds or so.
However linking the debug version takes many minutes, and the CPU is
pegged during the link.

FYI:
[gtalbot@germanium testsrc]$ gcc --version
gcc (GCC) 4.1.1 20070105 (Red Hat 4.1.1-51)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

[gtalbot@germanium testsrc]$ ld --version
GNU ld version 2.17.50.0.6-2 20061020
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of the GNU General Public License.  This program has absolutely no
warranty.

This has been driving me crazy, so I downloaded the source RPM, and
built ld with "-g" turned on, installed it, then linked my program with
oprofile running.  Here's the output:

CPU: AMD64 processors, speed 1000 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a
unit mask of 0x00 (No unit mask) count 100000
samples  %        symbol name
40486    49.3870  match_simple_wild
18375    22.4148  walk_wild_section_specs3_wild2
12473    15.2152  walk_wild_section_general
2536      3.0936  walk_wild_section_specs2_wild1
2483      3.0289  walk_wild_section_specs1_wild1
1347      1.6431  lang_size_sections_1
729       0.8893  lang_process
654       0.7978  walk_wild_section_specs4_wild2
413       0.5038  lang_do_assignments_1
358       0.4367  lang_add_section
318       0.3879  walk_wild
279       0.3403  walk_wild_consider_section
245       0.2989  insert_pad
239       0.2915  find_section
161       0.1964  ldlang_add_file
149       0.1818  stat_alloc
103       0.1256  lang_for_each_statement_worker
70        0.0854  section_already_linked
68        0.0830  build_link_order
64        0.0781  .plt
64        0.0781  new_statement
63        0.0769  walk_wild_file
57        0.0695  output_section_callback
34        0.0415  gldelf_x86_64_check_needed
30        0.0366  unique_section_p
27        0.0329  lang_one_common
25        0.0305  gldelf_x86_64_find_statement_assignment
24        0.0293  gldelf_x86_64_stat_needed
20        0.0244  lang_for_each_input_file
16        0.0195  walk_wild_section_specs1_wild0
13        0.0159  lang_statement_append
10        0.0122  gldelf_x86_64_vercheck
6         0.0073  walk_wild_section
5         0.0061  yyparse
4         0.0049  open_input_bfds
3         0.0037  gldelf_x86_64_after_open
3         0.0037  ldfile_open_file
3         0.0037  section_iterator_callback
3         0.0037  yylex
2         0.0024  gc_section_callback
2         0.0024  gldelf_x86_64_place_orphan
2         0.0024  lang_add_wild
2         0.0024  ldfile_try_open_bfd
2         0.0024  map_input_to_output_sections
1         0.0012  exp_fold_tree_1
1         0.0012  gldelf_x86_64_load_symbols
1         0.0012  gldelf_x86_64_parse_ld_so_conf
1         0.0012  gldelf_x86_64_search_needed
1         0.0012  gldelf_x86_64_try_needed
1         0.0012  input
1         0.0012  ldfile_open_file_search

Can anyone tell me what's going on here?  Is there a patch I can apply?
Is there some other option I can pass to either ld or gcc?

Thanks.

--
George T. Talbot
<gtalbot@locuspharma.com>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]